Background session: $CLAUDE_JOB_DIR writes trigger "sensitive file" prompt with non-persistent allow-list

Description

Background sessions instruct the agent to write temporary files to
$CLAUDE_JOB_DIR (= ~/.claude/jobs/<uuid>/). However, Claude Code marks
~/.claude/ as a sensitive directory, so every write to $CLAUDE_JOB_DIR
triggers a "sensitive file" permission prompt.

The "Yes, and always allow access to <uuid>/" option is tied to the specific
UUID of that session, so the next background job (with a new UUID) prompts
again. Users see the same dialog every session, with no way to permanently
allow it.

Repro

1. Run a long-running bash command in a background session; the agent wraps it

with > $CLAUDE_JOB_DIR/foo.log 2>&1

1. Observe: "Claude requested permissions to edit

/Users/<you>/.claude/jobs/<uuid>/foo.log which is a sensitive file"

1. Choose option 2 "Yes, and always allow access to <uuid>/"
2. Trigger another background job -- new UUID, dialog appears again

Internal contradiction

The system prompt for background sessions explicitly says:

Use $CLAUDE_JOB_DIR (/Users/<you>/.claude/jobs/<uuid>) for any temporary files (scripts, query files, intermediate outputs) instead of /tmp -- parallel bg jobs share /tmp and clobber each other's files.

But the same Claude Code marks writes to ~/.claude/ as sensitive. The
agent is told to write to a path that then triggers a permission prompt every time.

Proposed fix

Option 1 (preferred): Treat ~/.claude/jobs/** as a trusted write target
by default (not sensitive). It is Claude Code's own designated temp space for
background jobs -- not user config.

Option 2: Expose a stable non-UUID path (e.g. ~/.claude/jobs/current/
symlink pointing at the current UUID) so allow-list entries persist across
sessions.

Option 3: When the agent writes to $CLAUDE_JOB_DIR, treat it as a
trusted self-write (the path came from the harness itself).

Workaround

Add to ~/.claude/settings.json allow list:

"Write(/Users/<you>/.claude/jobs/**)"

This works but treats the symptom. The underlying issue is the inconsistency
between "use this dir" and "this dir is sensitive."

Environment

• Claude Code version: 2.1.142
• OS: macOS Darwin 25.5.0