Eric Traut
1e5b87b4d7
## Why This is part of an ongoing attempt to eliminate the TUI's direct dependency on core features. When we moved the TUI to the app server, we left a `legacy_core` shim that re-exported some remaining core symbols for the TUI. The intent was to eventually remove all of these. In this PR, we remove the symbols related to the Windows sandbox. The change should be behavior-neutral and low risk because it's just refactoring and removal of code that is now effectively dead. When working on this PR, I noticed a big existing problem that affects mixed-platform remoting. For example, if you run the TUI on a Linux box and remote into a Windows box, the TUI logic doesn't properly handle Windows sandbox setup properly. Fixing this is beyond the scope of this PR, but I've left a TODO comment in place so we don't forget. ## What changed - Move the remaining TUI-specific sandbox level, setup, telemetry, and read-root helpers into `codex-tui`, calling `codex-windows-sandbox` directly. - Remove the Windows sandbox namespace and read-root grant re-exports from the client-side `legacy_core` facade. - Remove the dormant pre-elevation prompt fallback guarded by the permanently enabled `ELEVATED_SANDBOX_NUX_ENABLED` switch. The reachable elevated and non-elevated setup flows remain unchanged.
codex-app-server-client
Shared in-process app-server client used by conversational CLI surfaces:
codex-execcodex-tui
Purpose
This crate centralizes startup and lifecycle management for an in-process
codex-app-server runtime, so CLI clients do not need to duplicate:
- app-server bootstrap and initialize handshake
- in-memory request/event transport wiring
- lifecycle orchestration around caller-provided startup identity
- graceful shutdown behavior
Startup identity
Callers pass both the app-server SessionSource and the initialize
client_info.name explicitly when starting the facade.
That keeps thread metadata (for example in thread/list and thread/read)
aligned with the originating runtime without baking TUI/exec-specific policy
into the shared client layer.
Transport model
The in-process path uses typed channels:
- client -> server:
ClientRequest/ClientNotification - server -> client:
InProcessServerEventServerRequestServerNotificationLegacyNotification
JSON serialization is still used at external transport boundaries (stdio/websocket), but the in-process hot path is typed.
Typed requests still receive app-server responses through the JSON-RPC result envelope internally. That is intentional: the in-process path is meant to preserve app-server semantics while removing the process boundary, not to introduce a second response contract.
Bootstrap behavior
The client facade starts an already-initialized in-process runtime, but thread bootstrap still follows normal app-server flow:
- caller sends
thread/startorthread/resume - app-server returns the immediate typed response
- richer session metadata may arrive later as a
SessionConfiguredlegacy event
Surfaces such as TUI and exec may therefore need a short bootstrap phase where they reconcile startup response data with later events.
Backpressure and shutdown
- Queues are bounded and use
DEFAULT_IN_PROCESS_CHANNEL_CAPACITYby default. - Full queues return explicit overload behavior instead of unbounded growth.
shutdown()performs a bounded graceful shutdown and then aborts if timeout is exceeded.
If the client falls behind on event consumption, the worker emits
InProcessServerEvent::Lagged and may reject pending server requests so
approval flows do not hang indefinitely behind a saturated queue.