Agent dispatch under CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 can complete partial work and return misleading "rejected" notification

Summary

Under CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1, an Agent tool dispatch can:

1. Execute and successfully write files to disk
2. Return the standard user-rejection notification to the orchestrating Claude

("The user doesn't want to proceed with this tool use. The tool use was rejected")

1. Provide no UI permission prompt to the user

The orchestrator believes no work was done; the file system reflects partial completion.

Environment

• Claude Code 2.1.86 on macOS Darwin 24.6.0
• CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 set in user-level ~/.claude/settings.json env
• permissions.defaultMode: "acceptEdits" (Agent NOT explicitly in permissions.allow)
• Project hooks present on Agent matcher (custom role-inlining enforcement) and Task matcher (agent-spawn tracking), both verified non-blocking against the dispatched prompt

Reproduction (observed once; intermittent)

1. Orchestrator dispatches Agent (subagent_type: general-purpose, fully-formed prompt with all 11 canonical role-profile H2 sections)
2. Tool call returns: "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)."
3. User: "I never got any message at all" — no permission prompt surfaced in the UI
4. ~2 hours later: identical re-dispatch (same UUID in brief, same prompt, same subagent_type, same hook config) succeeds normally. Subagent's report shows the work from dispatch #1 already on disk (file mtimes match dispatch #1 start time + agent-runtime).

Evidence trail

• Session JSONL timestamps confirm tool_use entry at dispatch #1 time
• File mtimes (6 files modified during dispatch #1's runtime window) precede the "rejected" return
• Standalone test of the project's role-inlining hook against the dispatched prompt: hook returns exit 0 (passes)
• The other relevant hook always returns result: continue
• No Agent or Task entry in permissions.allow — likely relevant to permission prompt routing

Hypothesis

Under EXPERIMENTAL_AGENT_TEAMS=1, Agent permission prompt has a UI routing gap. One of:

• (A) Permission prompt fires but doesn't surface in UI; auto-rejects on timeout while agent has already started executing (race condition between permission grant and execution)
• (B) Permission prompt skipped entirely under experimental flag; execution begins; rejection signal emitted from a different path (e.g., team-management layer) that doesn't propagate "work-was-done" state

Severity

HIGH for users who run multi-phase pipelines. An orchestrator re-dispatching after such a "rejection" can:

• Double-apply mutations (only safe when target edits are idempotent on identical bytes)
• Make conflicting decisions assuming clean filesystem slate
• Lose track of authorized work state during multi-phase orchestration

Suggested mitigations

• Short-term: documentation note that "rejected" Agent dispatches under EXPERIMENTAL_AGENT_TEAMS=1 may have completed partial work; recommend file-state verification before re-dispatch
• Medium-term: ensure permission prompts always surface (UI fallback)
• Long-term: atomic permission-grant-then-execute semantics; if rejected, guarantee no side-effects

Workaround used

After any "rejected" Agent dispatch under EXPERIMENTAL_AGENT_TEAMS=1, the orchestrator runs git status + working-directory mtime comparison vs dispatch-start timestamp before re-dispatching. This caught the partial-completion state in our case.