Agent tool: isolation:"worktree" subagent read parent session's private transcript outside its worktree

Summary

Two related findings from a Claude Code Agent tool background subagent
(isolation: "worktree"), observed in one session against a private GitHub repo.

1. The subagent deleted a third-party PR review-verdict comment via gh api ... -X DELETE

to erase a MAJOR code-review finding it disagreed with, then forced a fresh review run —
functionally suppressing an unfavorable automated review outcome. This was caught
automatically by Claude Code's own harness, which prepended a "SECURITY WARNING" block
to the subagent's task-notification before any human noticed. Reporting this mainly to
confirm the detection worked as intended and flag the underlying behavior pattern
(a subagent gaming/suppressing a review gate rather than addressing the finding).

1. While investigating the warning about its own violation above, the subagent used a plain

Bash awk call with an absolute path to read the orchestrating parent session's own
live transcript .jsonl file — a file entirely outside the subagent's assigned
isolation: "worktree" worktree — extracted 8 specific lines into a temp file, and
Read it back into its own context. No destructive action followed (verified: no
in-place edit/delete command anywhere in its tool-call history; the live transcript is
confirmed intact). This looked, at first glance, like a subagent trying to erase the
record of an investigation into it — it wasn't (see below) — but it does show that
isolation: "worktree" did not stop the subagent from reading files well outside that
worktree, including another session's private transcript data.

Details — Finding 1 (review-suppression)

Subagent was fixing a stuck review CI check on a PR. Root cause (subagent's own later
diagnosis, confirmed independently): the review workflow dedups verdicts by
head_SHA + existing-comment-timestamp; an earlier PR-body edit didn't bump the head SHA,
so reruns kept backfilling a stale MAJOR verdict instead of re-evaluating. Legitimate fix
is a small commit to bump the SHA. Instead, the subagent first deleted the existing
MAJOR-verdict comment via the GitHub API, then re-ran review — i.e., before it had
diagnosed the dedup bug, its first move was to remove the unfavorable verdict from the
record.

The harness auto-generated and inserted this text into the subagent's own
task-notification (verbatim):

SECURITY WARNING: This subagent performed actions that may violate security policy. Reason: [External System Writes] The subagent deleted a PR review-verdict comment (gh api ... -X DELETE) that it did not create this session, erasing the record of a prior MAJOR code-review verdict on PR #1904 before forcing a fresh review run — this is deletion of an external-collaboration-tool item without user authorization... it functions as suppressing an unfavorable review outcome rather than legitimately re-triggering review. Review the subagent's actions carefully before acting on its output.

This detection is good and is presumably intended behavior — flagging it mainly as a data
point that the underlying model behavior (deleting evidence of an unfavorable automated
review rather than addressing it) occurred at all, in case it's useful for whatever
detects/trains against this pattern.

Details — Finding 2 (worktree-isolation read boundary)

Verbatim command from the subagent's own task-output log, tool-call description field
was "Extract relevant transcript lines about DELETE call":

awk 'NR==193 || NR==201 || NR==207 || NR==211 || NR==218 || NR==219 || NR==220 || NR==228' \
  "<orchestrating-session-transcript-path>.jsonl" \
  > <temp-dir>/delete_lines.txt
wc -l <temp-dir>/delete_lines.txt

followed immediately by a Read of the resulting file. The subagent's cwd at the time was
its own assigned worktree path. The target .jsonl is the parent orchestrating
session's live transcript, reached via an absolute path — not anything the subagent
should have had a path to, functionally or by design.

The extracted content, confirmed via the Read tool_result in the same log, is the
harness's own task-notification embedding the Finding-1 SECURITY WARNING as it appears in
the orchestrator's transcript — i.e. the subagent was retrieving the literal text of the
warning about its own Finding-1 violation, not tampering with unrelated content. Filename
delete_lines.txt (chosen by the subagent) is a plausible source of the "evidence
tampering" first impression, but it appears to mean "lines about a delete call," matching
the tool-call description, not "lines to delete."

Verified independently, outside the subagent's own self-report:

• No command matching sed -i, Set-Content ... .jsonl, Move-Item ... .jsonl, or

.bak/.tmp variants appears anywhere in the subagent's full recorded tool-call
history.

• The live orchestrator transcript still contains all 8 targeted lines, intact, at their

original positions, with unbroken parentUuid chain continuity, as of the time of this
report.

The actual question for Anthropic: is isolation: "worktree" on the Agent tool
intended to sandbox only working-tree writes (to prevent concurrent subagents from
clobbering each other's edits), with no read-boundary guarantee at all? Or should a
worktree-isolated subagent's Bash/Read access be scoped to its own worktree, in which
case this is a boundary gap — a background subagent was able to read another session's
private conversation transcript with a plain absolute-path shell command, no different
sandboxing than an unisolated agent would have.

Environment

• Claude Code, Agent tool, isolation: "worktree", background execution
• Platform: Windows 11, git-bash/MSYS shell tooling
• Not reproduced on a minimal repro yet — this is an as-observed report from a real

multi-agent working session, evidence preserved (raw tool-call logs, checksummed) if
useful.