[claude-opus-4-6] Task output and background commands hardcoded to /tmp with no way to override

Resolved 💬 3 comments Opened Mar 12, 2026 by mycroftcanner Closed Mar 16, 2026

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

  1. 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.

  1. Then tried to read those output files with TaskOutput, which also hits /tmp.
  2. The hook correctly blocked the reads, but by then the files were already written to /tmp.
  3. 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:

  1. Add a hook that blocks /tmp access
  2. Ask Claude to run any long-running command
  3. Claude will use run_in_background, writing to /tmp
  4. TaskOutput reads fail due to the hook
  5. 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!

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗