CRW-122 Phase 1 · 유휴 감독 전달: 스레드 승인 정책을 가정하지 말고 보존한다

[thisisjun786]

The defect

A parent sending a recovery or merge-turn return to an idle supervisor whose approvalPolicy
is on-request was refused with unsupported_approval_policy before turn/start, so the
report could never be delivered. Steering an active supervisor worked, which is why documents
and manual recovery survived while idle-supervisor report-then-resume did not.

Reproduced against a real isolated app-server (codex-cli 0.154.0, its own CODEX_HOME, no
credentials — nothing live was touched):

status              failed
rpcError.code       unsupported_approval_policy
findings[0]         expected "never", returned "on-request"
attemptedEffects    ["thread/resume"]
turn/start count    0

Cause

The approval policy was a constructor default that no caller could set
(settings.py approval_policy="never"). Two separate faults followed:

• resume_params() transmitted approvalPolicy: "never" on every resume that requested
  anything. That is asking to set the policy of a thread this bridge did not create.
• findings() judged the host's answer against that same assumed never, so any thread that was
  not already never was refused before a turn could start.

The change

The caller now declares the policy it believes the thread is on, and the resume carries no
approvalPolicy at all.

• Preservation is a property of the request. A parameter that is never sent cannot move a
  policy, whichever host is on the other end. ThreadResumeParams.approvalPolicy is optional;
  ThreadResumeResponse requires approvalPolicy and approvalsReviewer, so the truth is
  always observable without asking for anything.
• The guard is intact and now honest. Its predicate moves from "observed is not never" to
  "observed is not the declared one", which is how a supervisor whose state moved under the
  caller gets caught rather than written to. Omitting the key declares never, so every existing
  caller keeps exactly its previous behaviour, including its previous refusal.
• Delivery is not approval servicing. The bridge still answers every server-to-client request
  with a JSON-RPC error, which declines to decide; answering in the approval vocabulary
  (approved/decline) would write a verdict in the approver's own type and make the bridge the
  approver. Those refusals are now recorded, keyed by threadId/turnId, so "this bridge
  granted nothing" is evidence rather than an assurance.
• delivery is derived in reconcile from attemptedEffects, never pre-written. A death
  between the turn/start frame and its response can therefore never leave a receipt that says
  outcome_unknown beside not_delivered — which would tell the next caller it is safe to resend.

Nothing is relaxed: no policy is forced to never, no guard is deleted, no sandbox or approval
setting is widened, and create_thread/create_worktree_thread still set never on the threads
they create.

Measured, not assumed

The whole design rests on "omitting the parameter preserves the policy". That was originally
inferred from schema optionality; the architect review flagged it, so it was measured on
codex-cli 0.154.0 in both directions with isolated CODEX_HOMEs:

thread policy	config.approval_policy	resume with no parameter
on-request	never	reports on-request
never	on-request	reports never

Read twice each; nothing persisted. Omission preserves and does not inherit the config
default. Separately measured: a resume transmitting never against an on-request thread comes
back on-request and does not persist, so on this host the old transmission was an ill-shaped
request rather than a live relaxation. Both facts are stated separately and neither is overclaimed.

Tests

12 new tests, red-green verified against the original source: declared delivery to an
on-request idle thread; the guard still refusing when nothing is declared; a policy that changed
under the caller; a granular policy that can be observed but never declared; an explicit null
declaration refused locally; the resume never carrying approvalPolicy; an approval request
refused and never decided; a refusal preserved as not_delivered with zero turn/start; and
recovery processing one logical message exactly once across replayed refusals, a corrected
declaration and repeated ACKs.

conftest.py gains a fake that acts on the resume parameter. Against it, the old resume would
have moved an on-request supervisor to never and then reported success, because the value it
found was the value it had just written. The default fake models the measured host, which ignores
the parameter — a fake that could only do that would have assumed the conclusion.

Validation

The one check the Protect dev ruleset requires is dev-gate, and it is success on the current
head. That ruleset also requires every review thread to be resolved (all five are) and requires the
branch to be current with dev at merge time — it is 4 commits behind with zero file overlap, which
is an integration step for whoever merges, not a defect here.

The external GitHub Codex reviewer is not a required gate under Jun's current policy, which
disabled it. It is not requested or re-requested on new heads, and an absent, pending or skipped
Codex review is recorded as not required by user policy rather than as a passing check. Devin
review and all repository-required CI are unaffected.

CI is green on the current head 4e3c7c8, base 763ce15: run to be recorded below, attempt 1, event pull_request —
validate, tests (3.10), tests (3.13), packages (3.11), packages (3.13), secrets and
dev-gate all success; release-gate skipped.

Locally: scripts/ci/validate.py, scripts/ci/contracts.py, runtime_install.py verify-definition
and git diff origin/dev --check pass; bridge suite 198 passed, relay suite 1239 passed / 1 skipped.

Two local results are sandbox artifacts rather than code, and CI covers both:

• scripts/ci/tests reports one error — test_a_tilde_settings_path_is_absolute_once_the_hook_opens_it
  writes to $HOME, which is read-only in this sandbox. This PR touches no CI test file.
• scripts/ci/packages.py cannot run locally: /var/tmp is read-only and /tmp contains a stray
  .git, exactly the condition its own temporary_root() docstring warns about. The 38
  test_worktree.py failures it causes reproduce identically on the original source. Both
  packages legs pass in CI.

scripts/crw_runtime/components.json: only the codex-thread-bridge entry's three digests are
re-derived. The codex-session-relay entry is untouched — it belongs to CRW-120 / #58.

Review round

Five findings, all real, all fixed and each answered in thread with evidence before its thread was
resolved. Two came from the external Codex reviewer, which Jun has since disabled; that changes
nothing about them. A reported defect is an obligation regardless of who reported it, so none of
these was auto-resolved or discarded when the reviewer went away, and no unrelated improvement was
absorbed alongside them.

• Null policy became never (Devin, marked resolved). The selection tested the value instead
  of the key's presence, so an explicit null silently became never — the same "a discarded key
  looks like a setting never requested" failure the unknown-key refusal beside it exists to stop.
  Keyed on presence now, with a regression test.
• Trailing whitespace (Devin, marked resolved). Real, and so was the methodology error behind
  it: the original git diff --check ran after committing against a clean tree, so it compared
  nothing and this description repeated that empty result as a pass. Re-checked against the base.
• Stale guidance (Codex P1 + P2). The package README still said the policy is always never
  and interactive threads are always refused, and the bridge reference omitted the key entirely —
  so a caller following either would have kept hitting the original failure. Both updated.
• Contradictory approval claim (Codex P2). APPROVAL_LIMITS asserted categorically that a
  refused approval is never shown to the thread's approver, while get_capabilities said
  host-side forwarding is unverified — two opposing claims in one object, and the categorical one
  was the unmeasured half. The claim is now limited to what is established: this bridge has no
  forwarding route and nothing it does turns such a request into an approval.

Scope

This PR now covers both phases of CRW-122. Phase 2 was gated on CRW-120 while that PR was in
flight; CRW-120 has since landed on dev and the gate was released, so the relay half is
implemented here rather than deferred.

Phase 2, in packages/codex-session-relay, built against the landed linkage.py:

• delivery.resolve_recipient reads linkage.up(relationship_id=...) instead of taking the
  recipient off the relationship row, which freezes its parent at registration. It verifies
  rather than overrides: a linkage owner that disagrees with the row is refused as
  relation_owner_drift, so a completion arriving after the project changed hands is never filed
  as the new owner's result. An unreadable store is refused as relation_unreadable and never
  falls back to the frozen row; nothing found is unregistered_scope; two live owners is
  duplicate_scope_owner and is not resolved by picking. A resolved state that still carries
  contention is not treated as a resolved owner either — that is the handover window where the
  project binding can still name the outgoing parent while the issue edge names the incoming one.
• AssignmentView.project_state reads a project's completion from its children via
  linkage.attached() and outstanding(). It returns a reading, not a verdict: the strongest
  state is complete_candidate, because integration and verification are the parent's judgment.
  Partial Done cannot close it (the outstanding set must be empty, not small), a shared project
  cannot be closed by one parent (the set is the project's), and a child's own goal status is
  never consulted.
• linkage.py itself is untouched; both consumers only read it, and both take the linkage as an
  optional argument so every pre-existing caller keeps its behaviour.

22 targeted tests across test_delivery_relation.py and test_project_completion.py, red-green
verified: against dev's relay source the files cannot even import.

Known limits, recorded rather than closed

• Whether a refused approval reaches the owning client is unverified. This bridge has no
  forwarding route — the protocol offers no method by which a second client hands an approval
  request to the client that owns the thread. Whether the host independently surfaces it is not
  established: measuring it needs a model actually requesting approval, and the isolated
  CODEX_HOME has no credentials (measured 401). Left unverified everywhere it is mentioned.
• codex-session-relay still hardcodes never (settings.py:190, :222;
  schema/delivery-attempt.json:63). It belongs to CRW-120 / CRW-115: move a manual install to the plugin install, and own update, failure, disable and removal #58, so the claim here is scoped to
  direct bridge callers, and the relay change is returned to the coordinator as a follow-up.
• The declared policy is a caller-side assertion, not an operator-controlled one. Routing it
  through ExecutionPolicy is a deliberate Phase 1 non-goal: the declared value is never
  transmitted, so the most a caller can do is correctly name the policy of the thread it addresses.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-19T21:29:25.332213Z	0525971	New commits
🔒 Security Review	✅ Completed 2026-09-19T21:35:41.014506Z	0525971	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[thisisjun786]

@codex security review

[chatgpt-codex-connector]

🛡️ Codex Security Review

Security review completed. No security issues were found in this pull request.

Reviewed commit: 0525971f9f

View security finding report

Only the user who started this review can view the report in Codex.

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

• You comment "@codex security review"
• A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.