Show pending agent approvals across Omar’s web UI

[mrrkrieg]

When an agent pauses for permission, Omar’s web UI otherwise keeps showing it as running. This adds approval visibility for both topology agents and the executive assistant, including before a topology exists.

• Orange “Waiting for approval” indicators and a header count identify the affected agent without stopping other agents.
• The request panel shows the action, scope and waiting duration, and opens that agent’s existing terminal for a response.
• Reload and reconnect retain pending requests; backend acknowledgements resolve them, explicit denials are reported as denied, and run teardown cancels remaining requests.

Backend separation

ApprovalHub owns backend-neutral request identity, invocation correlation, timestamps, connection state and retention. ApprovalObserver implementations publish through an ApprovalSink and own their transport, parsing, replay and reconciliation. The capability registry in src/approvals/backends/mod.rs currently registers only Codex; another backend can be added by implementing an observer and registering its factory without changing the hub or UI.

Codex socket discovery, WebSocket JSON-RPC, request parsing and protocol fixtures live in backends/codex.rs. Both topology agents and the executive assistant select an observer by backend identity. Unsupported backends report unsupported immediately instead of starting a Codex monitor.

Existing launch defaults and operator permission settings are preserved. The observer does not respond to approvals, change approval policy, or force a backend into unattended mode because notifications are unavailable. Existing Claude/Antigravity skip-permissions and Cursor yolo defaults remain as configured.

Support and limits

The Codex observer handles command/file/permission requests, MCP elicitations and MCP tool approval questions. It falls back to the explicit waitingOnApproval flag when history/subscription is unavailable, and retries detailed subscription. Ordinary questions and silence are not classified as approvals. Unsupported integrations remain accessible through the terminal.

Independent /v1/approvals snapshot and SSE endpoints carry generated wire types. Arbitrary tool arguments, results and private reasoning are excluded. Pending state survives page reloads; daemon restart relies on backend rediscovery/replay. There is no inline approval endpoint. See docs/approvals.md for the adapter contract and support details.

Validation

• After integrating current upstream main: 429 Rust tests pass, including all 13 approval tests; 7 upstream tests remain marked ignored. A simulated second observer exercises shared identity, invocation correlation, disconnect retention and run teardown; registry tests cover supported and unsupported backends. Existing Codex Unix WebSocket/replay fixtures remain passing.
• Clippy --all-targets -- -D warnings, formatting and generated protocol checks pass.
• All 52 Playwright tests pass on the merged branch, including approval visibility and persistent assistant terminal access. The hosted build and frontend lint pass.
• Original feature validation also covered 13 web unit/protocol tests, embedded builds and 18 conformance/embedded-UI checks (one expected opposite-build-mode skip).
• Merged current upstream main and resolved the executor/terminal UI conflicts while preserving both behaviors.
• GitHub CI and Web workflows pass on the final commit.
• Approval lifecycle tests are deterministic fixtures; no live model approval was submitted. The live Omar instance was not used.

Activity/progress visibility remains separate in #247.

[lsk567]

I like this idea a lot! Thanks for working on this. However, the code seems to show that this is only implemented for codex, which I think it's fine to start with. But is it possible to factor the code into an abstraction to easily support the next agent backend like claude code?

Here is an instance of the tight coupling that I think we should remove, discovered by GPT 6 Astra:

ApprovalHub::watch directly launches the Codex monitor and takes a socket
plus a supported boolean. There is no observer interface or backend factory separating generic state management from Codex transport, parsing, and reconciliation.

One way is to maintain a list of backends that support this kind of approval notification (currently codex only). For those that are supported, the ApprovalHub::watch can launch a backend-specific monitor. For those that are not, we keep them in yolo mode so they never ask for permissions during execution. What do you think? @mrrkrieg

[mrrkrieg]

I like that - I'm going to work on that