codex app-server emits approval requests but lacks a strict approval response RPC #14192

Summary

codex app-server appears to emit approval request notifications, but in strict protocol-only mode it does not expose a usable approval response RPC for the controller to call back into.

When fallback/emulation paths are removed, live approval flows fail with:

Approval RPC method is not supported by the connected bridge.

Environment

• Codex LAN controller repo driving codex app-server
• Date observed: 2026-03-10
• Controller configured for strict protocol-only approval handling
• Live suite run against a fresh isolated controller/state, not a reused background process

Reproduction

1. Start a fresh controller instance that launches codex app-server.

2. Use a prompt that triggers a command approval, for example:

   Use the shell to run \open -g -a Calculator`. If approval is required, request it and then continue after approval. When complete, reply with exactly DONE.`

3. Wait for the real approval request event.

4. Call the controller approval endpoint, which forwards to the discovered upstream approval responder:

   POST /api/thread/:id/approvals/respond

5. Observe the upstream response behavior.

Expected behavior

If codex app-server can emit a real approval request, it should also expose at least one real approval response RPC that clears the pending approval state.

Examples of protocol shapes a controller can support:

• approval/respond
• approval/resolve
• approval/approve
• approval/reject
• equivalent permission/turn-scoped variants

The important part is that there is a documented, supported RPC path for approving or rejecting a pending approval request without local fallback emulation.

Actual behavior

In strict protocol-only mode, the controller cannot find a supported upstream approval response RPC.

The live flow fails with:

Approval RPC method is not supported by the connected bridge.

Before removing fallback discovery, the controller could also discover command/exec:callId:decision, but that behaves like a fallback/emulation path rather than a real approval contract and does not satisfy strict protocol-only approval handling.

Why this matters

Controllers built on top of codex app-server need deterministic approval semantics:

• request event appears
• user approves or rejects
• controller calls one supported upstream approval RPC
• approval resolves or rejects deterministically

Without a real response RPC, downstream integrations either:

• cannot support approvals reliably, or
• must reintroduce local fallback/emulation behavior that breaks the protocol contract

Additional notes

• This was tested after isolating the live harness so it no longer reused stale controller processes or state files.
• Deterministic local/fixture tests pass on the controller side.
• The remaining blocker is upstream approval response protocol support from codex app-server.