Skip to content

feat(stop-review-gate): add monorepo mode for sibling git repos#353

Open
PAzter1101 wants to merge 1 commit into
openai:mainfrom
PAzter1101:feat/monorepo-stop-review-gate
Open

feat(stop-review-gate): add monorepo mode for sibling git repos#353
PAzter1101 wants to merge 1 commit into
openai:mainfrom
PAzter1101:feat/monorepo-stop-review-gate

Conversation

@PAzter1101
Copy link
Copy Markdown

@PAzter1101 PAzter1101 commented May 27, 2026

Summary

The stop-time review gate currently resolves a single workspace via git rev-parse --show-toplevel from the session cwd. In layouts where several independent git repos sit under one parent directory (a common monorepo pattern — sibling clones managed by convention rather than git submodules), changes Claude makes in a sibling repo are silently skipped: the hook runs review only in the primary repo, sees no diff there, returns ALLOW, the session ends without the review actually covering the work.

This PR adds an opt-in monorepoMode config flag (default false, fully backwards-compatible). When enabled on the primary repo, the Stop hook scans the parent directory for sibling git repos and runs an independent stop-time review for each one that

  • has its own stopReviewGate enabled, and
  • has uncommitted changes.

Empty-diff siblings are skipped (Codex would just reply ALLOW and waste tokens). If any review blocks, the combined reason is returned and the gate blocks the Stop.

When monorepoMode is off (the default), behavior is identical to today: only the primary workspace is reviewed.

Configuration

/codex:setup --enable-monorepo
/codex:setup --disable-monorepo

Setup must still be run separately in each sibling repo to enable the gate for it (/codex:setup --enable-review-gate). The hook respects each sibling's own state — a repo whose gate is off is skipped.

Why opt-in

  • Auto-scanning the parent dir without an explicit opt-in could surprise users with single-repo workflows where the parent happens to contain other git checkouts (e.g. ~/code/ with dozens of unrelated clones).
  • Keeps single-repo semantics deterministic and free of any FS walk.

Test plan

  • npm test — 86 → 88 tests (two new state tests for the flag); only pre-existing failures remain (test: isolate saveState pruning test from shared git-repo state dir #133-style flake on resolveStateDir and the status/result formatter tests). No regressions from this change.
  • End-to-end stop hook tests in tests/runtime.test.mjs (which set up a git repo + a committed change) continue to pass — primary workspace review path is unchanged.

Out of scope

The stop-time review gate resolves the workspace via `git rev-parse
--show-toplevel` from the session cwd. In layouts where several
independent git repositories live under one parent directory (a common
monorepo pattern with submodules-like checkouts or just by convention)
this means changes Claude makes in sibling repos are silently skipped
by the hook — the gate runs in the primary repo, sees no diff there,
returns ALLOW, and the session ends without any review of the actual
work.

This change adds an opt-in `monorepoMode` config flag (default `false`,
fully backwards-compatible). When enabled on the primary repo, the
`Stop` hook also scans the parent directory for sibling git repos, and
for each one that
  - has its own `stopReviewGate` enabled, and
  - has uncommitted changes,
runs an independent stop-time review. Empty-diff siblings are skipped
(Codex would just reply ALLOW and waste tokens). If any review blocks,
the combined reason is returned and the gate blocks the Stop.

Single-repo behavior is unchanged: when `monorepoMode` is off (the
default), only the primary workspace is reviewed exactly as before.

Configurable via:
  /codex:setup --enable-monorepo
  /codex:setup --disable-monorepo

Tests cover the config defaults and persistence. The hook behavior is
exercised end-to-end by the existing `tests/runtime.test.mjs` stop hook
tests, which still pass.
@PAzter1101 PAzter1101 requested a review from a team May 27, 2026 12:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant