Question
An agent in a dl workspace writes two kinds of state. Its transcript reaches the host and survives. Its scratchpad stays in the container and dies with it. Should the scratchpad survive too, and if so, where does it land?
Claude Code gives each session a scratchpad directory and tells the agent to use it for every intermediate file: scripts, captured output, generated patches, notes that do not belong in the repo. The path is /tmp/claude-<uid>/<cwd-slug>/<session-id>/scratchpad. Under /tmp, so container-local.
What was measured
On this host, ~/.claude/projects/ holds 45 directories named -workspaces-*. Each one is a session that ran inside a container, and its transcript is on the host disk now. That works because .devcontainer/claude-code/devcontainer-feature.json binds the directory read-write:
source=${localEnv:HOME}/.claude,target=/home/vscode/.claude,type=bind
with CLAUDE_CONFIG_DIR=/home/vscode/.claude beside it.
On the same host, /tmp/claude-1000/ holds 0 directories named -workspaces-*. Every scratchpad those 45 sessions wrote is gone, or is sitting in a container waiting to be pruned.
Nothing in the repo touches the path. grep -rn '/tmp/claude\|scratchpad' over the tree returns three unrelated hits in TROUBLESHOOTING.md, all of them debug log paths.
The asymmetry is the whole report: the same session, the same agent, one channel kept and one channel dropped, and the dropped one is where the working files are.
Why it costs something
A transcript records what the agent said it did. The scratchpad holds what it actually built. When a run is picked up later — a retry, a review, a diagnosis of why the run went wrong — the transcript names files that no longer exist.
dl --prune and an ordinary workspace delete both take the scratchpad with them, silently. Nothing warns, because nothing knows the directory is there.
What is not verified
I did not open a running workspace and read the path from inside it. The claim that the scratchpad is container-local follows from the mount list — /tmp is not in it — and from the host evidence above, not from a direct observation in a container. Worth confirming before anyone builds on it.
I also did not check whether Claude Code lets the scratchpad root be moved by configuration. If it does, that is a smaller fix than a mount.
Suggested shape, not a decision
Bind a host directory to the scratchpad root, the way ~/.claude is already bound. Something under ~/.cache/devlaunch/ keeps it beside the verdict cache and out of the way of the host's own sessions.
Two things to settle first, because they are the reason this is a question and not a patch:
- Isolation. One shared host directory is visible to every container at once. Today a workspace cannot see another workspace's working files. A naive bind ends that. Per-workspace subdirectories keep the property; a single shared root does not.
- Disk. #458 and the 43GB measured under one repo's workspaces say this host already loses disk to things nobody prunes. A scratchpad that survives the container needs an owner that deletes it, or it becomes the next sink.
Question
An agent in a
dlworkspace writes two kinds of state. Its transcript reaches the host and survives. Its scratchpad stays in the container and dies with it. Should the scratchpad survive too, and if so, where does it land?Claude Code gives each session a scratchpad directory and tells the agent to use it for every intermediate file: scripts, captured output, generated patches, notes that do not belong in the repo. The path is
/tmp/claude-<uid>/<cwd-slug>/<session-id>/scratchpad. Under/tmp, so container-local.What was measured
On this host,
~/.claude/projects/holds 45 directories named-workspaces-*. Each one is a session that ran inside a container, and its transcript is on the host disk now. That works because.devcontainer/claude-code/devcontainer-feature.jsonbinds the directory read-write:with
CLAUDE_CONFIG_DIR=/home/vscode/.claudebeside it.On the same host,
/tmp/claude-1000/holds 0 directories named-workspaces-*. Every scratchpad those 45 sessions wrote is gone, or is sitting in a container waiting to be pruned.Nothing in the repo touches the path.
grep -rn '/tmp/claude\|scratchpad'over the tree returns three unrelated hits inTROUBLESHOOTING.md, all of them debug log paths.The asymmetry is the whole report: the same session, the same agent, one channel kept and one channel dropped, and the dropped one is where the working files are.
Why it costs something
A transcript records what the agent said it did. The scratchpad holds what it actually built. When a run is picked up later — a retry, a review, a diagnosis of why the run went wrong — the transcript names files that no longer exist.
dl --pruneand an ordinary workspace delete both take the scratchpad with them, silently. Nothing warns, because nothing knows the directory is there.What is not verified
I did not open a running workspace and read the path from inside it. The claim that the scratchpad is container-local follows from the mount list —
/tmpis not in it — and from the host evidence above, not from a direct observation in a container. Worth confirming before anyone builds on it.I also did not check whether Claude Code lets the scratchpad root be moved by configuration. If it does, that is a smaller fix than a mount.
Suggested shape, not a decision
Bind a host directory to the scratchpad root, the way
~/.claudeis already bound. Something under~/.cache/devlaunch/keeps it beside the verdict cache and out of the way of the host's own sessions.Two things to settle first, because they are the reason this is a question and not a patch: