[Bug] Codex agent gets stuck on permission prompts — requests never surface in UI

[aslkhon]

Description

When using the Codex agent in 1code, operations that require user approval (running code, writing files, executing tests, etc.) cause the agent to get stuck. Codex announces it is requesting permission, but the prompt never appears in the UI. The agent remains in a "running" state indefinitely with no way to approve, deny, or cancel.

In the standard Codex CLI or VS Code extension, these permission prompts are shown interactively and the user can approve/deny them.

Steps to Reproduce

1. Start a Codex agent session in 1code
2. Ask Codex to perform an operation that requires approval (e.g., run tests, execute code)
3. Codex announces it is requesting permission
4. Agent gets stuck in "running" state — no prompt appears in the UI

Root Cause Analysis

After investigating the codebase (v0.0.83), the issue has two layers:

1. setPermissionRequestHandler is never wired up

The ACP provider library (@mcpc-tech/acp-ai-provider) exposes a setPermissionRequestHandler(handler) method on ACPAISDKClient for handling session/request_permission events from the Codex CLI. However, codex.ts (the Codex router) never registers a handler after calling createACPProvider(). The default fallback in the SDK auto-selects the first option, but this doesn't resolve correctly for all permission types.

2. Codex CLI stdin is closed

The Codex CLI process is spawned with stdio: ["ignore", "pipe", "pipe"], meaning stdin is completely closed. If Codex CLI falls back to stdin-based prompting for certain operations (outside the ACP protocol), it hangs forever waiting for input that can never arrive — which matches the "stuck in running" behavior.

For comparison: how Claude agent handles this

The Claude agent sidesteps the problem entirely by using allowDangerouslySkipPermissions: true in the Claude router, which bypasses all permission checks in agent mode.

Suggested Fix

Option A (Proper fix): Wire up the permission flow end-to-end:

1. Call provider.setPermissionRequestHandler() in the Codex router after creating the provider
2. Emit permission request events to the renderer via the existing tRPC subscription (similar to how Claude's AskUserQuestion tool emits events through pendingUserQuestionsAtom)
3. Build a permission approval dialog in the renderer (could reuse patterns from mcp-approval-dialog.tsx)
4. Send the user's response back through the handler's return value

Option B (Quick workaround): Pass a flag to the Codex CLI to run in full-auto mode, bypassing permission prompts entirely (similar to how the Claude agent uses allowDangerouslySkipPermissions). Less safe but immediately unblocks users.

Environment

• 1code v0.0.83 (confirmed still present)
• macOS (likely affects all platforms)
• Codex agent via ACP provider