fix(codex): stop review-mode exec from exploring the repo; raise budget to 600s

[AngeloAdam]

Why (in your own words)

On a large monorepo, /codex review with custom instructions kept dying at exit 124. Downstream agents reported it to me as "codex is unavailable" — so I spent time checking the binary, the auth, the MCP connectors, all of which were fine. The actual failure is in this skill.

The custom-instructions path runs codex exec, which — unlike codex review --base — is not auto-scoped to the diff. It gets a full read-only sandbox over the repo and goes exploring. The prompt bounds the filesystem (~/.claude/, agents/) but never tells the model to stay off the tree, so on a big repo it burns the whole 330s wrapper grepping and produces empty stdout. Empty stdout after a timeout is indistinguishable from a model stall, which is why it gets misreported as an availability problem rather than a scoping one.

gstack's own operational-learning loop had already caught this and logged it a day before I found it — codex exec on a large repo burns the whole 330s wrapper budget exploring (403KB of grep output, empty stdout, reads as a stall) — but the learning was never applied to the skill.

Live evidence

Before. The skill has no instruction against exploration anywhere — the only boundary is the filesystem one:

$ grep -rn -iE "no-explore|do not explore|explor" ~/.gstack/render/claude/codex/SKILL.md \
    ~/.gstack/render/claude/codex/sections/review-mode.md
(no matches)

And the logged learning that predicted the failure:

$ grep -o '"key":"codex-exec-must-forbid-repo-exploration".*"insight":"[^"]*"' \
    ~/.gstack/projects/<slug>/learnings.jsonl
"key":"codex-exec-must-forbid-repo-exploration"
"insight":"codex exec on a large repo burns the whole 330s wrapper budget exploring
 (403KB of grep output, empty stdout, reads as a stall). Adding an explicit no-explore
 instruction plus feeding the diff inline returns tagged findings in well under the budget."

After. Ran the patched exec path end to end against a real 23-file / 1,649-insertion / 103KB diff, timed, with the exact prompt the skill now builds:

prompt bytes:   102991
EXIT=0 ELAPSED=324s
tokens used
54,231

Output — a real verdict, not an empty stall:

No [P1] or [P2] findings.

Verdict: approve based solely on the inlined diff. The changes preserve
failure/absence semantics, constrain build-time degradation, and include
targeted regression coverage.

Exploration is gone — zero tool invocations in stderr:

$ grep -cE "^(exec|bash|rg |grep |find |ls )" codex-err-fixed.txt
0

Why the timeout moves too. Note the 324s above: with exploration fully suppressed, that diff still lands only six seconds under the old 330s ceiling. The no-explore instruction alone does not make this path safe at that size — the remaining time is reasoning at model_reasoning_effort="high". So the wrapper goes 330 → 600s and the Bash gate 360000 → 660000, which also collapses review onto the same budget challenge and consult already use instead of documenting a third one.

Scope

• Changed: codex/sections/review-mode.md.tmpl — added a SCOPE: line to the codex exec prompt (no repo exploration; no grep/find/ls/rg across the tree; at most 5 targeted file reads, and only to confirm an already-named finding), and raised both review paths from the 330s wrapper / timeout: 360000 gate to 600s / 660000. codex/SKILL.md.tmpl — updated the two places that documented the old 330/360000 pair. Rendered .md files regenerated from the templates and committed alongside them.
• Verified live by: running the patched exec path against a real 103KB diff on a private monorepo (numbers above); confirming the deployed skill at ~/.gstack/render/claude/codex/ carries both changes after ./setup; bun test test/codex-hardening.test.ts test/codex-web-search-flag.test.ts test/skill-validation.test.ts.
• Did NOT test: the --xhigh path, --commit / --uncommitted scopes, or any host other than claude. I also did not test whether 600s is sufficient for diffs substantially larger than 103KB — I suspect it is not, and the better lever there is probably splitting the diff or dropping to medium effort rather than raising the ceiling again.

On the test suite: it is flaky on my machine in a way unrelated to this change. Same suite, same commit, back to back: 52 pass / 2 fail then 54 pass / 0 fail. Clean main at 0d1bd56 fails 6 of the same set before my change is applied. The failures are timing-sensitive (gstack-slug, broken-install detection, and two grep -rln tests that exceed the 5000ms default while scanning the install dir) plus a tracked-binaries check. None reference review-mode.md or the timeout constants.

Liveness proof (required)

⚠️ Not attached yet — @AngeloAdam is adding it.

Being straightforward about this: the branch was prepared by Claude (Claude Code) at the repo owner's direction, and the timed runs above were executed by it on the owner's machine. The liveness screenshot exists precisely to confirm a human is behind the PR, so it is not mine to produce — an agent generating it would defeat the check it is there to perform. @AngeloAdam will attach a real one. Until it lands, please treat this as not meeting the evidence bar, regardless of the ready-for-review state.

Checklist

• Liveness screenshot attached — pending from @AngeloAdam, see above
• This is not a generated-file-only diff (I edited the templates and regenerated via gen:skill-docs, then deployed with ./setup)
• No ETHOS.md edits, and no changes to voice / founder perspective / YC references
• N/A — no new public command, external service, or host adapter
• Linked issue or reproduction: none filed; the reproduction is the timed run above

🤖 Generated with Claude Code

[trunk-io]

Merging to main in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[AngeloAdam]