Cloud routines: read-only access (cp) to persisted tool-results files triggers 'sensitive file' edit permission prompt — unattended runs hang forever in requires_action

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 20, 2026

Summary

In cloud routine (scheduled agent) sessions, when a tool call returns an oversized result, the harness persists it to ~/.claude/projects/**/tool-results/ and instructs the model to read it from there. But any subsequent Bash command that merely references such a file — including a plain read-only cp <tool-results-file> <scratchpad> with no write to the source — triggers:

permission prompt Bash: Claude requested permissions to edit /root/.claude/projects/-home-user/<uuid>/tool-results/<file> which is a sensitive file.

Since routine runs are unattended, nobody can answer the prompt and the session hangs indefinitely with worker_status: requires_action. There is no timeout, no failure, and no notification — the routine silently stops producing output until a human opens the session page.

Why this looks like a bug

  1. Per the permissions docs, cp is classified as a read-only command that should not prompt. The prompt also says "edit" although the command only reads the file.
  2. The tool-results file is the session's own tool output that the harness itself told the model to consume ("Output has been saved to … Use offset and limit parameters to read specific portions of the file"). Reading it back should not be treated as touching sensitive Claude config.
  3. The behavior is nondeterministic: across identical daily runs of the same routine, some of these prompts auto-resolve after ~13–33 seconds and the run completes; others hang forever. In one run the first cp batch resolved in 13s and a second, same-shaped cp batch minutes later hung permanently.

Repro (cloud routine)

  1. Create a routine whose prompt requires processing a large tool result, e.g. WebFetch of a ~1MB artifact page, or an MCP connector query returning a multi-MB JSON (result gets persisted to tool-results/).
  2. Have the prompt instruct: "copy the persisted file to the scratchpad with cp, then only work on the copy" (added specifically to avoid editing the sensitive path).
  3. Fire the routine (cron or run-now), unattended.
  4. Observe via the runs list: session enters requires_action at the first Bash command that references the tool-results path, and never proceeds.

Observed on model=claude-sonnet-5 routine sessions, multiple days in a row (4 of 5 recent runs hung; 1 completed after the prompt auto-resolved).

Impact

Any unattended routine that must process large WebFetch/MCP results is unreliable — the harness forces large results into tool-results/, and consuming them from Bash rolls the dice on a permission prompt that unattended sessions can't answer. There is also no API to cancel or approve a stuck run programmatically.

Expected

  • Read-only access (cp/cat/python open-for-read) to the session's own tool-results/ files should not require a sensitive-file edit permission, or
  • routines should be able to pre-authorize this in their job config, or at minimum
  • an unanswered permission prompt in an unattended routine should fail the run after a timeout (so failure is visible) instead of hanging in requires_action forever.

🤖 Generated with Claude Code

View original on GitHub ↗