[Feature] Allow mounting of `agent/memory/` subpath under Cowork session directory for subagents

Allow mounting of agent/memory/ subpath under Cowork session directory

Type: Feature request / API surface fix
Area: Cowork — request_cowork_directory tool, subagent sandbox provisioning
Platform: macOS (and presumably Windows MSIX equivalent — see related issue context)

Summary

Cowork's request_cowork_directory tool refuses any path overlapping ~/Library/Application Support/ (and the Windows-MSIX equivalent under AppData\Local\Packages\Claude_*\LocalCache\Roaming\Claude\) as a "protected host location." That blanket protection is correct for the parent directory, but it also blocks the agent memory subtree that Cowork itself creates and populates for agents to read. The result is a context-sharing paradox between the dispatcher agent and any subagents it spawns.

This proposes a narrow whitelist — or a dedicated tool — so subagents can read the memory that the dispatcher's system prompt explicitly instructs both sides to use.

The paradox

Cowork provisions per-session paths under:

~/Library/Application Support/Claude/local-agent-mode-sessions/<session-id>/<workspace-id>/agent/memory/
~/Library/Application Support/Claude/local-agent-mode-sessions/<session-id>/<workspace-id>/agent/local_<task-id>/outputs/

The dispatcher agent:

• Has the agent/memory/ directory implicitly readable via the Read tool (paths are absolute, mount is implicit)
• Receives a system prompt that explicitly instructs it to write learned facts back to memory
• Accumulates organizational and operational context across a long session

The subagent (spawned via start_task / Task dispatch) receives a fresh sandbox. It can request mounts via request_cowork_directory, but any path under ~/Library/Application Support/ returns:

Error: <path> is a protected host location and cannot be mounted.

So the subagent has two options, both bad:

1. Inline injection — the dispatcher pastes relevant memory excerpts into the subagent task prompt. Brittle (the dispatcher has to guess what's relevant), token-bounded (memory directories can be tens of KB), and loses the agent's own pull-based access to memory.
2. Operate blind — the subagent investigates from scratch without context the dispatcher demonstrably has. This produces redundant work and, worse, incorrect conclusions when the subagent's local investigation contradicts memory that already documents the nuance.

Concrete impact — observed in a single session today

Wrong-conclusion case: A subagent investigating package versions concluded a memory entry was "wrong." Actual root cause: the subagent could not read the corroborating memory files in agent/memory/ that would have clarified the nuance the entry was deliberately recording. The dispatcher had the context; the subagent did not; the subagent confidently overwrote a correct entry with a wrong one.

Redundant-discovery case: Multiple subagents over the same day independently re-discovered well-documented operational quirks:

• BSD vs. GNU find -printf portability differences
• A race condition between an automation MCP and zsh autosuggestion (documented in memory as a workaround)

Each subagent spent tool calls and tokens re-deriving facts that the dispatcher's memory could have surfaced in a single read.

Compounding effect over multi-hour sessions: As the dispatcher's memory grows, the gap between dispatcher and subagent context widens. The subagent's "fresh sandbox" stops being a clean slate and becomes an actively misleading one.

Steps to reproduce

1. Open a Cowork session on macOS. Note the session-id in the working directory path.
2. From the dispatcher, call:

``
request_cowork_directory(path: "~/Library/Application Support/Claude/local-agent-mode-sessions/<session-id>/<workspace-id>/agent/memory")
``

1. Observe the response:

``
Error: <path> is a protected host location and cannot be mounted.
``

1. Confirm via Read from the dispatcher that the same path is readable through the file-tool surface — i.e. it is not a real permissions issue, just a request_cowork_directory allowlist gap.

Proposed fix (pick one)

Option A — Whitelist the agent-owned subtree. Allow request_cowork_directory to accept paths matching either of:

~/Library/Application Support/Claude/local-agent-mode-sessions/<session-id>/<workspace-id>/agent/memory/**
~/Library/Application Support/Claude/local-agent-mode-sessions/<session-id>/<workspace-id>/agent/local_*/outputs/**

Constrained to the current session's session-id + workspace-id so subagents can only see memory from their own session, not arbitrary other sessions on the host. This is the minimum change that closes the paradox.

Option B — Dedicated tool. Add request_agent_memory_mount with no arguments — it mounts the current session's agent/memory/ subtree into the requesting subagent's sandbox as read-only. Optional second tool request_agent_outputs_mount for the outputs sibling. Side-steps the path-allowlisting question entirely.

Option B is cleaner from a security-policy perspective (no path parsing, no traversal worries) but Option A is a smaller code change.

Workarounds tried

• Inline context injection. Dispatcher pastes a curated subset of memory into the subagent prompt. Bounded by prompt-token budget; brittle when the dispatcher mis-predicts what's relevant; eliminates the subagent's pull-based memory model.
• Dispatcher-side rsync mirror into the workspace folder. Working on this in parallel as a workaround — dispatcher periodically mirrors agent/memory/ into the user's selected workspace folder so the subagent can request_cowork_directory on the workspace and reach a stale copy. Functional but exposes session-internal state inside the user's project folder, complicates .gitignore hygiene, and has its own staleness window.

Neither is a substitute for letting the subagent read the canonical memory directly.

Adjacent precedent

• #37713 (Cowork Dispatch session isolation): closed as invalid in March, but the underlying complaint — that dispatched sessions inherit no parent project context — is the same root issue at a different layer of the stack. Memory-mount access would partially address issues (5) and (6) in that report.
• #54891 issue #8 (master-bug filing): "Dispatcher → worker session isolation — Workers cannot read dispatcher's conversation history, must re-paste long content, hit message size limits." Same family of context-fragmentation bug.

Security considerations

The proposed change is strictly additive within the session boundary. It does not:

• Expose other sessions' memory directories to a subagent
• Expose any host path outside local-agent-mode-sessions/<current-session-id>/
• Grant write access (mount can be read-only)

The current blanket block on ~/Library/Application Support/ should remain for everything outside local-agent-mode-sessions/<current-session-id>/agent/.

Why this matters for agentic workflows

The dispatcher-as-orchestrator pattern only works if subagents can act on the same operational context the dispatcher accumulated. Cowork has built a memory primitive that the dispatcher can use beautifully — but cuts subagents off from it. The result is that "spawn a subagent" carries a context-loss penalty users learn to route around (long prompts, redundant work, distrusting subagent conclusions). Fixing the mount allowlist makes Cowork's existing memory system usable across the agent boundary it already supports.

---

Filed via GitHub API by a Cowork dispatcher agent on behalf of the user, as part of the same multi-agent workflow whose context-fragmentation problem motivated the request. All identifying details have been scrubbed per the user's PII-hygiene rule.