Fix Codex app-server ownership and protocol admission

docs/vrs/05-harness-state/requirements.md

@@ -117,7 +117,7 @@ authorizes or changes delivery.
   nothing there awaits a human (matching the projection's
   `Held { Review }` → `active` / `blockedOn: none` row) — while
   `WaitingOnApproval` and `WaitingOnUserInput` report `active` with
-  `blockedOn: human`. `Compaction` reports `active`, and
+  `blockedOn: human`. `Compaction` and `UnknownProtocol` report `active`, and
   `NotLoaded`/`SystemError`/`AwaitingStatus` withhold rather than write.
   `Held` — a delivery predicate — never appears in the published vocabulary.
 - **OHS-R06 Heartbeat only on evidence:** A writer re-stamps the record on the
@@ -195,8 +195,9 @@ The measurements are #268's, taken 2026-08-16/17 on one host and carried with
 their original caveats: 1298 presence files all legacy one-line records, 4
 transitions per turn 0.1–0.4 ms apart, Claude hook timelines (blocked entry in
 2 of 9 captures, exit in 1), silent Claude death under SIGTERM/SIGKILL, and
-the Codex `activeFlags` schema present on all supported codex-cli versions
-(#268's first comment). The shipped code evidence is in-repo: the Codex state
+the Codex `activeFlags` schema present in the measured codex-cli versions
+(#268's first comment). The startup gate now checks that generated schema
+directly. The shipped code evidence is in-repo: the Codex state
 machine and its hold reasons, the unfiltered agent-dir watch beside the
 presence refresh that writes into it, and `src/harness_state.rs`, which
 implements the envelope this file ratifies.

docs/vrs/05-harness-state/spec.md

@@ -183,11 +183,21 @@ comes first. The cross-check is a narrowing of the ungraceful-death window
 (provably dead sessions: pidfile present, process gone), not its closure —
 OHS-T04/OHS-R07 say exactly this, and no death tombstone is attempted: the
 kill that removes the registry entry leaves nothing behind to prove death
-with, and fabricating evidence is the one thing this design never does. A Codex
-binary whose delivery-critical schema projection does not match an admitted
-fingerprint produces no Codex observed state at all: provider launch is refused
-before the control channel starts. Fingerprint admission and live behavioral
-evidence remain separate.
+with, and fabricating evidence is the one thing this design never does.
+
+Each controlled Codex startup generates the installed app-server schema. st2
+checks the required methods, response fields, blocking flags, and data shapes
+that native delivery uses. A compatible patch or minor release starts without
+a source change. A missing required element or a changed critical shape stops
+before the app-server starts. The wrapper sends one idempotent rejection report
+to the agent's declared supervisor. The version string is diagnostic data, not
+an admission proxy.
+
+Additive item kinds and server-request methods do not stop startup. A listed
+element is reviewed and safe to ignore. An unlisted element creates an
+`UnknownProtocol` delivery hold. The next safe thread status releases the hold.
+This fail-closed runtime rule keeps the agent present and prevents a silent
+delivery into a new hold that st2 does not understand.
 
 ## Codex producer (OHS-R05)
 
@@ -205,6 +215,7 @@ complement of steerable, a delivery predicate (decision 0001's boundary).
 | `Held { ConflictingTurn }` | `active` | `none` | `none` | `conflictingTurn` — two turns believed live is maximally active |
 | `Held { Review }` | `active` | `none` | `none` | `review` — review's enter and exit are model-emitted items inside a running turn; nothing awaits a human |
 | `Held { Compaction }` | `active` | `none` | `none` | `compaction` |
+| `Held { UnknownProtocol }` | `active` | `none` | `none` | `unknownProtocol` — an additive protocol element blocks delivery until a safe thread status arrives |
 | `Held { WaitingOnApproval }` | `active` | `human` | `permission` | `waitingOnApproval` |
 | `Held { WaitingOnUserInput }` | `active` | `human` | `question` | `waitingOnUserInput` |
 | `Held { NotLoaded }` | *withhold* | — | — | thread not loaded proves nothing about work |

docs/vrs/spec.md

@@ -1065,9 +1065,9 @@ policy, compat field, or API version constant — but it does publish its
 TypeScript declarations, and those govern this coupling.
 `checks.pi-extension-types` type-checks the shipped extension against a pinned
 pi release at build time, which is what makes the asset's otherwise-erased
-`import type` load-bearing. This follows the repo's existing rule that st2 pins
-where skew fails silently (`pty`, `codex-cli`) and not where it fails loudly
-(`claude`); the extension's one silent surface was its idle proof, and using
+`import type` load-bearing. This follows the repo's existing rule that st2 validates
+where skew fails silently (`pty`, the Codex app-server schema) and not where it fails
+loudly (`claude`); the extension's one silent surface was its idle proof, and using
 that proof without calling it is now a build error.
 
 A pi agent never enters the DING path. `deliver` and `ding` are mutually