consult impl-review subagent resolves relative 'Changed Files' paths against outer checkout, not worktree

[colleen110]

Symptom

When consult runs an implementation review (--type impl / --type integration) against a builder operating in a git worktree (e.g. .builders/<branch>/...), the reviewing sub-agent reads the outer repo's files instead of the worktree's files. The review's verdicts describe main branch content, not the builder's actual committed changes — producing false REQUEST_CHANGES.

Codev version: @cluesmith/codev@2.1.5

Root cause (diagnosed by a builder running on studio-manager#484; full rebuttal: https://github.com/colleen110/studio-manager/blob/main/codev/projects/484-aspir-schedule-management-filt/484-phase_1-iter1-rebuttals.md)

buildImplQuery passes the reviewing model a "File List" of bare repo-relative paths (e.g. app/javascript/controllers/foo.js) plus "read the changed files from disk."

The sub-agent has no Bash access (allowedTools: ['Read', 'Glob', 'Grep']) and no explicit statement of its launching cwd, so it guesses the absolute base path to join with each entry. It guesses the outer checkout, not the worktree it was actually launched in — even though cwd is set correctly.

Reproduced by replaying the exact prompt through @anthropic-ai/claude-agent-sdk (claude-opus-4-6, same allowedTools/cwd/permissionMode) with tool-call logging:

TOOL_USE: Read {"file_path":"/Users/.../studio-manager/app/javascript/controllers/foo.js"}
TOOL_USE: Read {"file_path":"/Users/.../studio-manager/app/views/.../index.html.erb"}

— missing the .builders/<branch>/ segment.

When the sub-agent is handed an absolute worktree path directly (as happens for Spec/Plan paths included in the prompt), it reads correctly. So the bug is specifically in how the "Changed Files" relative-path list is presented.

Suggested fix

In buildImplQuery, expand each relative entry to an absolute path rooted at the worktree's cwd before handing the list to the sub-agent (or include the cwd explicitly in the prompt so the model can join correctly).

Impact

Every ASPIR/SPIR builder running in a worktree gets false REQUEST_CHANGES verdicts on any review that lists relative changed-file paths. Likely affects all current codev users using af spawn ... --protocol spir/aspir.

[amrmelsayed]

Cross-linking with #1018 (Builder worktree write-guard): same root cause, different surface, different severity.

Shared root cause

In both issues, a Claude session synthesizes an absolute path anchored at the inferred canonical repo root instead of its actual worktree cwd. The byte-identical sibling trees that Codev maintains (e.g. codev/ and codev-skeleton/, or the main checkout and .builders/<id>/) mask the wrong-rooted access because the path resolves to something that exists.

How the two surface differently

	#1018 (write surface)	#1092 (read surface)
Operation	Write / Edit by a builder agent	Read by a consult impl-review sub-agent
Outcome on wrong root	Pollutes the main checkout silently	Reads stale content from the outer repo
Visibility	Silent until manually spotted	Mostly self-healing (see below)
Severity	High	Low
Fix scope	Write-guard hook on builder writes	Absolutize the "Changed Files" list in buildImplQuery

Why this issue (#1092) is mostly self-healing in practice

Verified by replaying the exact prompt through @anthropic-ai/claude-agent-sdk 0.2.105 with tool-call logging. The consult sub-agent gets a plain-string systemPrompt that strips the env block, so it starts blind. First Read guess: bare /foo.txt. The not-found error returns with Note: your current working directory is <cwd> appended, and the model self-corrects to the worktree path on the next attempt.

Key asymmetry: that corrective cwd note only fires on is_error=true. When the wrong-root guess happens to hit an existing file (the #1018 scenario, where richer context anchors a plausible canonical-root guess that succeeds), there's no error and no note, so no self-correction happens. That asymmetry is why #1018 actually bites and #1092 is the cousin that mostly heals itself before producing a verdict.

The remaining failure mode for #1092 is the case where the wrong-rooted Read does succeed (i.e. the outer checkout has a file at the same relative path as the worktree). Then the verdict is built from stale content, surfacing as a false REQUEST_CHANGES. So this is real but bounded.

Note on #1018's fix not covering this

The write-guard hook proposed in #1018 does not address #1092: reads aren't writes, and a Read-side guard would be a different mechanism with different trade-offs. The fix proposed in this issue (absolutize the "Changed Files" list in buildImplQuery before handing it to the sub-agent) is the right scope for the read surface.

Scope correction to the original Impact section

The "Likely affects all current codev users using af spawn ... --protocol spir/aspir" claim is broader than the actual code path. Only review steps that route through buildImplQuery are affected:

--type value	Query builder	Affected?
impl	buildImplQuery	Yes
pr	buildPRQuery	No (paths are derived from PR diff, not from a relative file list)
integration	buildPRQuery	No
phase	buildPhaseQuery	(Needs separate verification; likely immune since phase consults don't ship a relative file list either)
spec / plan	individual handlers	No (these pass absolute paths directly)

The standard SPIR / ASPIR review steps that run at PR time use --type pr or --type integration and are immune. The affected case is specifically consult --type impl invocations, which are less common in normal workflow but real for impl-review-specific use cases (the original reporter's studio-manager#484 was one).

Suggested labels: area/consult. Priority is low given the self-healing path + the narrow surface.