host pre-flight runs the agent one-shot in the dispatcher cwd, causing spurious NO-GO on cross-repo issues #153

Closed
opened 2026-06-18 04:29:20 +00:00 by coilysiren · 4 comments
Owner

Symptom

ward agent goose headless coilyco-flight-deck/ward#131 was dispatched from a host cwd of ~/projects/coilyco-flight-deck/agentic-os. The host-side pre-flight ran goose run -t <prompt> in that cwd, so goose analyzed the agentic-os checkout, found no cmd/ward-kdl (it lives in the ward repo), and returned NO-GO - then commented NO-GO on ward#131 and launched nothing. Given the wrong cwd, the NO-GO was the correct refusal, but the input was wrong.

Root cause

runPreflight (cmd/ward/agent.go) -> containerMode.hostPreflightArgv (cmd/ward/container_compute.go) runs the agent's one-shot self-assessment on the host, in the dispatcher's cwd, via r.Runner.Capture. The prompt (preflightPrompt) asks "can you carry this issue?" but a filesystem-grounded agent like goose reads the repo it is sitting in rather than reasoning from the issue text. claude's -p read does not poke the host repo the same way, which is the observed claude/goose behaviour divergence.

Fix options

  • Make the pre-flight contract repo-neutral: prompt the agent to reason only from the issue body (already provided) and explicitly tell it not to inspect the host filesystem, since the target repo is not checked out here.
  • Or run the pre-flight against the resolved target repo (the same repo the container will fresh-clone), not the dispatcher cwd.

Surfaced while sweeping ward for hardcoded agent divergence (see ward#152). The per-agent pre-flight argv is part of the same surface that ward#152 moves into the aos-published agent-adapter manifest, but this cwd/prompt bug is fixable independently and should not wait on that refactor.

## Symptom `ward agent goose headless coilyco-flight-deck/ward#131` was dispatched from a host cwd of `~/projects/coilyco-flight-deck/agentic-os`. The host-side pre-flight ran `goose run -t <prompt>` **in that cwd**, so goose analyzed the `agentic-os` checkout, found no `cmd/ward-kdl` (it lives in the `ward` repo), and returned **NO-GO** - then commented NO-GO on ward#131 and launched nothing. Given the wrong cwd, the NO-GO was the *correct* refusal, but the input was wrong. ## Root cause `runPreflight` (`cmd/ward/agent.go`) -> `containerMode.hostPreflightArgv` (`cmd/ward/container_compute.go`) runs the agent's one-shot self-assessment **on the host, in the dispatcher's cwd**, via `r.Runner.Capture`. The prompt (`preflightPrompt`) asks "can you carry this issue?" but a filesystem-grounded agent like goose reads the repo it is sitting in rather than reasoning from the issue text. claude's `-p` read does not poke the host repo the same way, which is the observed claude/goose behaviour divergence. ## Fix options - Make the pre-flight contract **repo-neutral**: prompt the agent to reason only from the issue body (already provided) and explicitly tell it *not* to inspect the host filesystem, since the target repo is not checked out here. - Or run the pre-flight against the **resolved target repo** (the same repo the container will fresh-clone), not the dispatcher cwd. ## Related Surfaced while sweeping ward for hardcoded agent divergence (see ward#152). The per-agent pre-flight argv is part of the same surface that ward#152 moves into the aos-published agent-adapter manifest, but this cwd/prompt bug is fixable independently and should not wait on that refactor.
coilyco-ops added
P2
and removed
P3
labels 2026-06-24 04:11:59 +00:00
Member

Re-triage (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24)

  • P2 - Host pre-flight one-shots in the dispatcher cwd causing spurious NO-GO on cross-repo issues, diagnosed bug.
  • interactive - Pre-flight contract change with a few fix options, agent works it and pauses for the approach.
<!-- goose-triage --> **Re-triage** (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24) - **P2** - Host pre-flight one-shots in the dispatcher cwd causing spurious NO-GO on cross-repo issues, diagnosed bug. - **interactive** - Pre-flight contract change with a few fix options, agent works it and pauses for the approach.
Member

Re-triage (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24)

  • P2 - Host pre-flight one-shots in the dispatcher cwd causing spurious NO-GO on cross-repo issues, diagnosed bug.
  • interactive - Pre-flight contract change with a few fix options, agent works it and pauses for the approach.
<!-- goose-triage --> **Re-triage** (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24) - **P2** - Host pre-flight one-shots in the dispatcher cwd causing spurious NO-GO on cross-repo issues, diagnosed bug. - **interactive** - Pre-flight contract change with a few fix options, agent works it and pauses for the approach.
Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-153 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T17:59:15Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

<!-- ward-agent-reservation --> 🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-153` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T17:59:15Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides. <!-- ward-agent-signature --> — Claude (she/her), via `ward agent`
Author
Owner

WARD-OUTCOME: done - added a runPreflight-seam regression test + doc cross-ref pinning ward#153 closed; landed on main.

Honest retro: this one turned out to be already-fixed-but-never-closed. Reading the pre-flight subsystem first paid off immediately - the two levers that kill this bug (ward#169's neutral temp dir + repo-neutral prompt, and ward#162 barring local-model harnesses from the host one-shot) were already in place, and ward#169's commit had quietly closed a near-duplicate (#169) without ever cross-referencing #153. So the temptation was a fake code change to justify a commit. Instead I looked for the genuine gap and found one worth closing: nothing tied the full runPreflight(goose) -> proceed path to this incident, so a future rewire of goose's preflight argv that forgot the trust gate would silently reintroduce the cwd-NO-GO. The new test pins that seam.

What fought back: the container disk was already at 100%, and my own pre-commit/golangci caches tipped it over mid-session - the full test suite started failing with "no space left on device" TempDir errors that looked scary until I traced them to df, not my code. Freed ~160M of reclaimable caches and it went green. The other friction was the catalog hooks: the 4000-char doc cap and the 2-line comment-block rule both bit, so the ward#153 doc note is terser than I'd have liked (a bare parenthetical) - the fuller story lives in the commit body.

Confidence: high. The fix isn't mine - it was already robust and structural (the bar works regardless of what the agent does) - I'm just locking it against regression and recording that #153 is the incident it addresses. Rough edge / possible follow-up: the pre-flight prompt still has a mild internal tension (it tells the agent both "judge from issue text alone" and "this is the repository you should explore"), harmless with the neutral dir but slightly muddled wording someone could tighten later.

WARD-OUTCOME: done - added a runPreflight-seam regression test + doc cross-ref pinning ward#153 closed; landed on main. Honest retro: this one turned out to be already-fixed-but-never-closed. Reading the pre-flight subsystem first paid off immediately - the two levers that kill this bug (ward#169's neutral temp dir + repo-neutral prompt, and ward#162 barring local-model harnesses from the host one-shot) were already in place, and ward#169's commit had quietly closed a near-duplicate (#169) without ever cross-referencing #153. So the temptation was a fake code change to justify a commit. Instead I looked for the genuine gap and found one worth closing: nothing tied the *full* runPreflight(goose) -> proceed path to this incident, so a future rewire of goose's preflight argv that forgot the trust gate would silently reintroduce the cwd-NO-GO. The new test pins that seam. What fought back: the container disk was already at 100%, and my own pre-commit/golangci caches tipped it over mid-session - the full test suite started failing with "no space left on device" TempDir errors that looked scary until I traced them to df, not my code. Freed ~160M of reclaimable caches and it went green. The other friction was the catalog hooks: the 4000-char doc cap and the 2-line comment-block rule both bit, so the ward#153 doc note is terser than I'd have liked (a bare parenthetical) - the fuller story lives in the commit body. Confidence: high. The fix isn't mine - it was already robust and structural (the bar works regardless of what the agent does) - I'm just locking it against regression and recording that #153 is the incident it addresses. Rough edge / possible follow-up: the pre-flight prompt still has a mild internal tension (it tells the agent both "judge from issue text alone" and "this is the repository you should explore"), harmless with the neutral dir but slightly muddled wording someone could tighten later.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
coilyco-flight-deck/ward#153
No description provided.