claude-code - 💡(How to fix) Fix Agent tool rejection message shown but sub-agent still runs and modifies files [1 participants]

Summary

When an Agent tool invocation is rejected by the user (permission prompt declined), Claude Code displays the standard rejection message:

The user doesn't want to proceed with this tool use. The tool use was rejected (eg. if it was a file edit, the new_string was NOT written to the file).

However, the sub-agent actually runs to completion anyway — it executes tools, edits files on disk, and burns tokens. The parent (Opus in this case) believes the sub-agent was cancelled and continues based on that false assumption. The user sees files on disk mysteriously modified with no explanation.

Reproduction context

• Claude Code version: 2.1.118
• OS: macOS 14.6.0 (Darwin 24.6.0)
• Parent model: claude-opus-4-7 (1M context)
• Sub-agent type: general-purpose, model sonnet, foreground (not background)
• Two sub-agents launched in the same parent tool call batch (parallel). One was accepted, the other rejected by the user via the permission prompt.

Observed behavior

The rejected sub-agent:

• Received tool_use_result of type rejection in the parent conversation
• Was nonetheless spawned and persisted its transcript in ~/.claude/projects/<proj>/<session>/subagents/agent-<id>.jsonl
• Executed 286 transcript lines, 73 Bash calls, 26 Read, 13 Edit
• Modified files on disk (confirmed by cross-referencing the transcript's file_path entries with the working tree)
• Several of its edits were silently consumed by a lint-staged auto-stash during the accepted sub-agent's commit, leaving a confusing partial state in the index

Meanwhile the parent Opus, having read the "rejected" message, had moved on to other work — no monitoring, no cancellation, no awareness.

Impact

• User confusion — files modified without visible authorisation, difficult to trace back to an agent that the system explicitly said was rejected.
• Wasted quota — on a 5-hour Opus window, approximately 42% of the quota had been consumed when the user noticed, the rejected agent being a major contributor.
• Safety surface — any agent that can be invoked but not actually cancelled by the standard permission flow breaks the user's mental model of permissions. Users rely on rejection to mean "this did nothing."

Expected behavior

When a user rejects an Agent tool_use at the permission prompt:

1. The sub-agent MUST NOT be spawned, OR it MUST be terminated before any tool execution
2. No .jsonl transcript of executed tools should be persisted
3. No filesystem modification should occur
4. The parent's "rejected" message should be truthful

Suggested diagnostics to include if reproducing

• ~/.claude/projects/<project>/<session>/subagents/ — check for .jsonl transcripts of rejected agents
• ~/.claude/projects/<project>/<session>/subagents/*.meta.json — confirm which agents were launched
• git reflog of the working repo shows unexplained lint-staged stashes created during sibling agent commits