[claude-opus-4-6] Task output and background commands hardcoded to /tmp with no way to override
Preflight Checklist
- [x] I have searched existing issues for similar behavior reports
- [x] This report does NOT contain sensitive information (API keys, passwords, etc.)
Type of Behavior Issue
Claude ignored my instructions or configuration
What You Asked Claude to Do
I have tried everything to stop Claude Code from using /tmp — explicit instructions, CLAUDE.md rules, hooks that block access, correcting it mid-conversation. Nothing sticks. /tmp usage is one of the most persistently annoying behaviors in Claude Code. It keeps defaulting to /tmp for scratch files, intermediate outputs, and now run_in_background task output which can't even be overridden.
On macOS, /tmp is RAM-backed. Claude has filled up my RAM multiple times by dumping large outputs there. It has crashed its own context by writing huge files to /tmp and then trying to read them back. It has lost important work because it was operating out of /tmp and the files disappeared on reboot. I had to add a blanket hook to block all /tmp access just to protect my system, and now I discover that run_in_background. a built-in feature of the tool — is hardcoded to write there with no alternative path. So the feature is simply unusable.
I have a hook (block-tmp.sh) that blocks all access to /tmp and explicit instructions not to use /tmp. I asked Claude to run tests and restart a server.
What Claude Actually Did
- Used run_in_background: true on Bash tool calls (make test, make restart), which writes task output to
/private/tmp/claude-501/.../tasks/<id>.output — a hardcoded path with no override.
- Then tried to read those output files with TaskOutput, which also hits /tmp.
- The hook correctly blocked the reads, but by then the files were already written to /tmp.
- Even after being told not to use /tmp, the model reaches for run_in_background again in future turns because it's the "obvious" tool for
long-running commands. The instruction not to use /tmp doesn't help because the model doesn't connect run_in_background with /tmp. the /tmp
path is an invisible implementation detail.
Expected Behavior
- run_in_background task output directory should be configurable (env var, settings.json, or project-level config) instead of hardcoded to
/tmp.
- At minimum, if a user has hooks blocking /tmp, run_in_background should either respect that or surface a clear error at invocation time.
not silently write to /tmp and fail later on read.
- The dumb part: there is literally no way for a user to use run_in_background without /tmp writes. The feature is fundamentally broken for
anyone with a /tmp policy.
Files Affected
/private/tmp/claude-501/-Users-az-re-ida-headless-mcp/.../tasks/*.output (created by the runtime, not by user request)
Permission Mode
Accept Edits was ON (auto-accepting changes)
Can You Reproduce This?
Yes, every time with the same prompt
Steps to Reproduce
Steps to Reproduce:
- Add a hook that blocks /tmp access
- Ask Claude to run any long-running command
- Claude will use run_in_background, writing to /tmp
- TaskOutput reads fail due to the hook
- Tell Claude not to use /tmp — it stops using run_in_background but loses the ability to run non-blocking commands entirely
Claude Model
Sonnet
Relevant Conversation
why did you hit /tmp? any use of /tmpis prohibited.. I don't know who thought it was nice to have claude use /tmp for stuff that should survive reboot or just £$%&in' fill up my ram with garbage... that's why /tmp and find are blocked now
A configurable task_output_dir setting or defaulting to $XDG_STATE_HOME/claude/tasks/ would fix this. As it stands, the only workaround is to never use background tasks at all.
The hook blocks /tmp paths. The server tests all passed — the failure is likely just the worker test timing out. Let me verify by running the
tests fresh.
⏺ The run_in_background feature of the Bash tool writes its output to /tmp automatically — that's not something I chose. I used it for make test
and make restart to avoid blocking. I'll stop using run_in_background for bash commands and just run them inline with timeouts instead.
⏺ Write(~/.claude/projects/-Users-az-re-ida-headless-mcp/memory/feedback_no_tmp.md)
⎿ Wrote 11 lines to ../../.claude/projects/-Users-az-re-ida-headless-mcp/memory/feedback_no_tmp.md
1 ---
2 name: no-tmp-usage
3 description: Never use /tmp or run_in_background for Bash (it writes to /tmp). User has a hook blocking all /tmp access.
4 type: feedback
5 ---
6
7 Never use `run_in_background` for the Bash tool — it writes output to `/tmp` which is blocked by the user's hook.
8
9 **Why:** User considers /tmp usage wasteful (RAM-backed, doesn't survive reboot, accumulates garbage). A hook (`block-tmp.sh`) en
forces this.
… +1 line (ctrl+o to expand)
From the tool definition:
1. You set run_in_background: true on a Bash call
2. It immediately returns a task ID (e.g. b0zg9ausk)
3. The output gets written to a file under /private/tmp/claude-501/.../<task_id>.output
4. You're supposed to read it later with TaskOutput
So it's fundamentally /tmp-based — there's no way to configure the output path. Every backgrounded command creates garbage in /tmp.
That's why your hook caught it. I won't use it.
❯ is there any way to change the location of the output?
⏺ Not from my side — the output path is hardcoded by Claude Code's runtime. There's no parameter or config to change it.
You could file a feature request at https://github.com/anthropics/claude-code/issues to make the task output directory configurable.
❯ please draft an issue about the usage of /tmp ... use the word dumb in the issue epxlain that claude keeps ignoring instructions to not use
/tmp and the run in background tool also uses /tmp and there doesn't seem to be a way to prevent that.
Impact
Critical - Data loss or corrupted project
Claude Code Version
2.1.74 (Claude Code)
Platform
Anthropic API
Additional Context
Happens all the time!
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗