agent-goose.md and agent-codex.md claim image-baked, no self-install; container.md says both drop to a shell, not yet imaged

coilyco-ops commented

2026-07-01 22:12:59 +00:00

Owner

Why

Persona: oss-agent-power-user, angle install-path - specifically checking the READMEs promise that goose (an OSS local harness) is a first-class, symmetric option to claude. Two docs directly contradict each other on whether --driver goose (or --driver codex) actually launches the harness today:

docs/agent-goose.md, "## Install stance": "goose is image-baked from the launcher point of view. No self-install step."
docs/agent-codex.md, "## Install stance": "codex is image-baked from the launcher point of view. No self-install step."
docs/container.md, "## Modes" section, one paragraph below the driver table: "codex/goose drop to a shell (not yet imaged); qwen self-installs opencode."

These cannot both be true. Either goose/codex are baked into the dev-base image and launch normally (per their own per-harness docs), or invoking them drops the run into a bare shell because the binary isnt there yet (per container.md). For the exact persona checking "is claude the privileged path with OSS harnesses as afterthoughts" - this is the sharpest possible answer either way, and the docs wont commit to one. If container.md is current, then two of the four headline-promised harnesses (goose, codex) silently fail to launch as documented, which is adoption-fatal for anyone actually trying --driver goose.

Deliverable

Reconcile: confirm which statement is current (check via the sanctioned rule-3 peek if needed, or defer to whoever last touched the dev-base image), then fix the stale doc. If goose/codex genuinely drop to a shell, agent-goose.md/agent-codex.mds "Install stance" sections are actively wrong and should say so plainly, not "no self-install step."

Done condition

agent-goose.md, agent-codex.md, and container.md agree on whether each harness is actually launchable today, with no contradiction between the per-harness doc and the container-model doc.

Severity: adoption-fatal · persona: oss-agent-power-user · angle: install-path
Filed by Claude Code during a cold-read release pressure test (run 11).

## Why Persona: `oss-agent-power-user`, angle `install-path` - specifically checking the READMEs promise that goose (an OSS local harness) is a first-class, symmetric option to claude. Two docs directly contradict each other on whether `--driver goose` (or `--driver codex`) actually launches the harness today: - `docs/agent-goose.md`, "## Install stance": "goose is image-baked from the launcher point of view. No self-install step." - `docs/agent-codex.md`, "## Install stance": "codex is image-baked from the launcher point of view. No self-install step." - `docs/container.md`, "## Modes" section, one paragraph below the driver table: "codex/goose drop to a shell (not yet imaged); qwen self-installs opencode." These cannot both be true. Either `goose`/`codex` are baked into the dev-base image and launch normally (per their own per-harness docs), or invoking them drops the run into a bare shell because the binary isnt there yet (per `container.md`). For the exact persona checking "is claude the privileged path with OSS harnesses as afterthoughts" - this is the sharpest possible answer either way, and the docs wont commit to one. If `container.md` is current, then two of the four headline-promised harnesses (goose, codex) silently fail to launch as documented, which is adoption-fatal for anyone actually trying `--driver goose`. ## Deliverable Reconcile: confirm which statement is current (check via the sanctioned rule-3 peek if needed, or defer to whoever last touched the dev-base image), then fix the stale doc. If goose/codex genuinely drop to a shell, `agent-goose.md`/`agent-codex.md`s "Install stance" sections are actively wrong and should say so plainly, not "no self-install step." ## Done condition `agent-goose.md`, `agent-codex.md`, and `container.md` agree on whether each harness is actually launchable today, with no contradiction between the per-harness doc and the container-model doc. --- **Severity: adoption-fatal** · persona: oss-agent-power-user · angle: install-path Filed by Claude Code during a cold-read release pressure test (run 11).

coilyco-ops added the

pressure-test

label

2026-07-01 22:12:59 +00:00

coilyco-ops referenced this issue

2026-07-01 22:13:41 +00:00

meta: release pressure-test run log (cold-read usability sweeps) #428

coilyco-ops commented

2026-07-01 22:22:44 +00:00

Author

Owner

+1 — independently hit via oss-agent-power-user/install-path, this run. agent-goose.md and agent-codex.md say image-baked, but container.md still describes them as not yet imaged/shell fallback.

coilyco-ops referenced this issue

2026-07-01 22:24:36 +00:00

meta: release pressure-test run log (cold-read usability sweeps) #428

coilyco-ops added this to the ward launch milestone

2026-07-01 23:29:33 +00:00

coilyco-ops added the

labels

2026-07-01 23:30:27 +00:00

coilyco-ops referenced this issue

2026-07-02 00:01:42 +00:00

meta: jul 1st evening sprint - launch burndown session 1 #492

coilyco-ops commented

2026-07-02 02:48:59 +00:00

Author

Owner

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

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-456` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T02:48:56Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilysiren referenced this issue from a commit

2026-07-02 02:58:51 +00:00

docs(container): reconcile goose/codex launch stance with the imaged reality

coilysiren closed this issue

2026-07-02 02:58:52 +00:00

coilysiren commented

2026-07-02 02:59:39 +00:00

Owner

WARD-OUTCOME: done - reconciled the goose/codex launch stance; docs now agree they are image-baked, and the stale shell-fallback code messages are fixed.

Honest retro: the interesting part was that the answer flipped mid-investigation. My first read of the ward code said container.md was right (the runtime command -v fallback plus a comment literally calling codex/goose install "a follow-up"), but the sanctioned peek at agentic-os docker/dev-base/Dockerfile settled it: goose 1.39.0 and codex 0.142.5 are baked in, pinned, alongside claude. The commit that added them even says goose "dropped to a shell while the binary was absent" - past tense. So agent-goose.md/agent-codex.md were current and container.md was stale.

The twist: while I worked, main got a big docs refactor that had already deleted the "drop to a shell (not yet imaged)" line and moved the bake list into a new container-image.md. My container.md edit collided with that and was genuinely redundant, so I took main's version in the merge. What was left to fix - and still stale on main - were the two runtime shell-fallback messages in container_bootstrap.go and entrypoint.sh, which still called codex/goose install "a follow-up". Those are now accurate.

What fought back: the 80-line/4000-char doc size cap on container.md (main sits at ~3993 chars, near-zero headroom) and three concurrent pushes to main during the land. Confidence is high - the docs agree, and the fallback is now correctly framed as a safety net for a genuinely-absent binary (old/custom --image), not the default path. No follow-ups worth filing.

WARD-OUTCOME: done - reconciled the goose/codex launch stance; docs now agree they are image-baked, and the stale shell-fallback code messages are fixed. Honest retro: the interesting part was that the answer flipped mid-investigation. My first read of the ward code said container.md was right (the runtime `command -v` fallback plus a comment literally calling codex/goose install "a follow-up"), but the sanctioned peek at agentic-os `docker/dev-base/Dockerfile` settled it: goose 1.39.0 and codex 0.142.5 are baked in, pinned, alongside claude. The commit that added them even says goose "dropped to a shell while the binary was absent" - past tense. So agent-goose.md/agent-codex.md were current and container.md was stale. The twist: while I worked, main got a big docs refactor that had already deleted the "drop to a shell (not yet imaged)" line and moved the bake list into a new container-image.md. My container.md edit collided with that and was genuinely redundant, so I took main's version in the merge. What was left to fix - and still stale on main - were the two runtime shell-fallback messages in container_bootstrap.go and entrypoint.sh, which still called codex/goose install "a follow-up". Those are now accurate. What fought back: the 80-line/4000-char doc size cap on container.md (main sits at ~3993 chars, near-zero headroom) and three concurrent pushes to main during the land. Confidence is high - the docs agree, and the fallback is now correctly framed as a safety net for a genuinely-absent binary (old/custom --image), not the default path. No follow-ups worth filing.

coilyco-ops commented

2026-07-02 08:00:32 +00:00

Author

Owner

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

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-456` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T08:00:30Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilyco-ops commented

2026-07-02 08:00:36 +00:00

Author

Owner

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

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-456` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T08:00:30Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilyco-ops commented

2026-07-02 08:00:40 +00:00

Author

Owner

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

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-456` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T08:00:30Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilysiren referenced this issue from a commit

2026-07-02 08:04:19 +00:00

docs(agent): state codex/goose launch today, document the shell fallback (closes #456)

coilysiren commented

2026-07-02 08:04:58 +00:00

Owner

WARD-OUTCOME: done - agent-goose.md/agent-codex.md now state codex/goose ship in dev-base and launch today, with the drop-to-shell fallback documented as a missing-binary (qwen-only) safety net.

Honestly, this one was already half-fixed before I arrived. The exact contradictory sentence in container.md ("codex/goose drop to a shell (not yet imaged)") had been deleted the same day by #475 (6c69bc7), which rewrote that section for an unrelated reason and quietly took the bad line with it. So the sharpest part of the reconciliation - deciding which side was true - came down to reading the code, not the docs: container_bootstrap.go:311 and entrypoint.sh:883 both say plainly that claude/codex/goose ship in dev-base and only qwen self-installs opencode. The per-harness docs were the correct side all along.

What fought back a little: container.md was sitting at 3993/4000 chars, so I could not add the fallback note there even though it is arguably the most natural home. I put the clarification in the two per-harness "Install stance" sections instead, which had room, and left container.md untouched. The drop-to-shell behavior was previously documented in zero docs despite being real, so this is a genuine gap closed, not just churn.

Confidence is high - source of truth is the code, all pre-commit hooks pass, and the four docs (agent-drivers, agent-claude, agent-codex, agent-goose) plus container.md now agree. One rough edge worth a follow-up: doc-size cap contention. Several of these pages sit within a handful of chars of the 4000 cap, so the next edit to container.md will force a split or a trim. Might be worth filing a small "container.md is at cap" issue before it becomes a blocker mid-task for someone else.

WARD-OUTCOME: done - agent-goose.md/agent-codex.md now state codex/goose ship in dev-base and launch today, with the drop-to-shell fallback documented as a missing-binary (qwen-only) safety net. Honestly, this one was already half-fixed before I arrived. The exact contradictory sentence in container.md ("codex/goose drop to a shell (not yet imaged)") had been deleted the same day by #475 (6c69bc7), which rewrote that section for an unrelated reason and quietly took the bad line with it. So the sharpest part of the reconciliation - deciding which side was true - came down to reading the code, not the docs: container_bootstrap.go:311 and entrypoint.sh:883 both say plainly that claude/codex/goose ship in dev-base and only qwen self-installs opencode. The per-harness docs were the correct side all along. What fought back a little: container.md was sitting at 3993/4000 chars, so I could not add the fallback note there even though it is arguably the most natural home. I put the clarification in the two per-harness "Install stance" sections instead, which had room, and left container.md untouched. The drop-to-shell behavior was previously documented in zero docs despite being real, so this is a genuine gap closed, not just churn. Confidence is high - source of truth is the code, all pre-commit hooks pass, and the four docs (agent-drivers, agent-claude, agent-codex, agent-goose) plus container.md now agree. One rough edge worth a follow-up: doc-size cap contention. Several of these pages sit within a handful of chars of the 4000 cap, so the next edit to container.md will force a split or a trim. Might be worth filing a small "container.md is at cap" issue before it becomes a blocker mid-task for someone else.

coilysiren commented

2026-07-02 08:06:25 +00:00

Owner

Correction to my retro above, for the record: the container.md + code reconciliation was not only #475. A prior run on this issue (f0730d8, "reconcile goose/codex launch stance with the imaged reality") had already fixed container.md and the two code fallback messages (container_bootstrap.go, entrypoint.sh), then posted its own WARD-OUTCOME: done. But it left the per-harness agent-goose.md/agent-codex.md "Install stance" sections - the exact wording this issues Deliverable names - still hedgy ("image-baked from the launcher point of view"). So the issue read as done while its literal done-condition was not yet met. My commit ef1c5c0 finishes those two sections and documents the missing-binary drop-to-shell fallback, which no doc had. Net: two complementary #456 commits, both now on main, no conflict.

Correction to my retro above, for the record: the container.md + code reconciliation was not only #475. A prior run on *this* issue (f0730d8, "reconcile goose/codex launch stance with the imaged reality") had already fixed container.md and the two code fallback messages (container_bootstrap.go, entrypoint.sh), then posted its own WARD-OUTCOME: done. But it left the per-harness `agent-goose.md`/`agent-codex.md` "Install stance" sections - the exact wording this issues Deliverable names - still hedgy ("image-baked from the launcher point of view"). So the issue read as done while its literal done-condition was not yet met. My commit ef1c5c0 finishes those two sections and documents the missing-binary drop-to-shell fallback, which no doc had. Net: two complementary #456 commits, both now on main, no conflict.

Rows
Columns

agent-goose.md and agent-codex.md claim image-baked, no self-install; container.md says both drop to a shell, not yet imaged #456

Why

Deliverable

Done condition