Repository navigation
Python: Bound hosted harness file memory with quotas and retention #8900
Description
Problem
The hosted claw sample persists file memory under the current sandbox's $HOME. Trusted user/sandbox namespaces isolate access, but FileMemoryProvider.file_memory_write and FileSystemAgentFileStore do not enforce per-file byte limits, file-count limits, per-scope storage quotas, a shared-filesystem budget, or expiry/garbage collection. Repeated authorized writes can therefore exhaust persistent disk capacity and cause ENOSPC failures.
This was raised in the review of #8899: #8899 (comment) . The maintainer explicitly requested deferring the change from that PR and tracking it separately; do not disable or redesign the sample's file memory as part of that integration/isolation slice.
Scope
python/packages/core/agent_framework/_harness/: file-memory provider and filesystem-store boundaries.python/samples/02-agents/harness/build_your_own_claw/claw_step04_production_ready/hosted.pyand its README.- Consider externally backed file stores so the guarantees are explicit rather than assumed from the backend.
Acceptance criteria
- Define enforceable limits for individual writes, file count, per-user/sandbox storage, and shared storage capacity where applicable.
- Enforce limits before allocating/loading oversized payloads or committing writes, including concurrent writes; do not silently discard or truncate data.
- Provide operator-controlled retention/expiry and a server-driven garbage-collection lifecycle for abandoned scopes.
- Preserve trusted user/sandbox isolation and avoid exposing identity values or tokens in diagnostics.
- Surface quota/retention failures clearly and document the intended hosted behavior and required backend/operator configuration.
- Validate boundary limits, concurrent accounting, cross-scope isolation, expiry/cleanup and failure behavior without requiring live Azure resources.
Related: #8746 and #8899. No live hosted deployment or resource provisioning has been performed for this follow-up.
Metadata
Metadata
Type
Projects
- Status
Activity
eavanvalkenburg commentedon Oct 27, 2026
/plan Use the maintainer-established quota/retention need, but first align the smallest viable design with the current harness/file-store work and existing owners; #8970 was explicitly closed because its large implementation direction was not agreed, so do not resurrect that design or treat this request as implementation approval. Current file-memory writes update content, optional description and the rebuilt index under a process-local folder lock, while filesystem writes encode and truncate directly without storage quotas. Define the correct provider/store/operator boundary for pre-allocation per-write limits, file counts, per-trusted-scope and shared-backend budgets, replacement/index/description accounting and rejected writes leaving prior data intact. Distinguish process-local serialization from atomic admission across store instances/processes; compare the minimal safe backend capability or deployment restriction rather than promising unsupported distributed guarantees. Plan explicit operator-controlled expiry/server-driven garbage collection, active-use/continuation and cleanup-race behavior, failure reporting and backend requirements without silent truncation, eviction or unbounded fallback. Preserve trusted user/sandbox isolation and existing path/write contracts, and keep the separate Cosmos snapshot sample policy in #8901 separate. Cover boundary and concurrent accounting, cross-scope isolation, expiry/cleanup and injected failures with deterministic fake/local stores, without live Azure resources. Report unresolved policy decisions and a bounded staged scope for maintainer agreement before coding; retain both existing assignees and do not mark ready.