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

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.

1. Wait for the real approval request event.
2. Call the controller approval endpoint, which forwards to the discovered upstream approval responder:

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

1. 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.