[BUG]Codex / GPT-5.5 触发需要审批的工具调用后，1Code UI 一直卡在 Running command / Generating

[ningzhaoxing]

Bug: Codex / GPT-5.5 触发需要审批的工具调用后，1Code UI 一直卡在 Running command / Generating

现象

在 1Code 中使用 Codex / GPT-5.5 发起任务，模型触发需要权限审批的 shell 命令后，界面会一直停在：

• Running command: /bin/zsh,-lc,curl
• 底部状态保持 Generating...
• 不返回工具结果，也不结束当前 turn

示例命令：

curl -I -L --max-time 15 -A 'Mozilla/5.0 ...' https://www.jianshu.com/

复现路径

1. 在 1Code 中选择 Codex / GPT-5.5。
2. 发送类似任务：https://www.jianshu.com/ 非侵入式地漏洞挖掘一下这个网页
3. 模型执行到需要外部网络 / escalation 的 curl 命令。
4. UI 卡在 Running command，不会进入 finish。

会话日志证据

关键记录：

• 第一次普通 curl 有正常 function_call_output，返回 DNS 错误：line 30
• 第二次发起 sandbox_permissions: "require_escalated" 的 exec_command：line 35
• line 35 之后没有对应的 function_call_output / task_complete，所以前端一直等不到 finish

代码证据

Codex provider 创建时没有接入任何权限审批 handler，只传了 ACP 启动、env、auth、session 等配置：

源码位置

Codex chat 直接把 provider.tools 交给 streamText：

源码位置

Codex 前端 transport 只处理 session-init、auth-error、error、finish，没有处理 ACP session/request_permission 或 Codex 工具审批事件：

源码位置

对比 Claude 路径，Claude 有完整的工具审批/回传链路：

• pendingToolApprovals： claude.ts
• 等待用户响应并带 60s timeout： claude.ts
• respondToolApproval mutation： claude.ts
• 前端回传审批结果： active-chat.tsx

ACP 协议本身定义了 session/request_permission，这是 client-side 用户授权请求：

schema.json

当前使用的 @mcpc-tech/acp-ai-provider 内部有 requestPermission，但没有 handler 时会默认选择第一个 option，而不是交给 1Code UI：

index.mjs

同时 ACPProviderSettings 类型里也没有暴露 permission handler 配置项：

types.d.ts

初步判断

1Code 当前没有实现 Codex 工具审批的产品级处理链路。
当 Codex / GPT-5.5 发起 require_escalated 的工具调用时，前端没有审批 UI，后端也没有 pending approval 状态、超时兜底、拒绝/批准回传。结果就是流无法收到正常工具结果或 finish，UI 一直停在 Generating...。

期望行为

• Codex 触发敏感工具调用时，1Code 应显示审批 UI。
• 用户可以 approve / deny。
• 审批结果应回传给 Codex ACP。
• 如果超时或无法处理，应返回明确错误并结束本轮，不能无限卡住。

建议修复

1. 为 Codex ACP 接入 session/request_permission 处理链路。
2. 增加 Codex 侧 pendingToolApprovals / respondToolApproval 类似 Claude 的机制。
3. 前端支持 Codex 工具审批 UI 和回传。
4. 增加工具调用超时兜底，避免 UI 永久 Generating...。

[1code-async]

Task completed.

I'll analyze this issue by examining the codebase to understand the current implementation and provide a detailed plan.

---

View full conversation

Powered by 1Code

[1code-async]

Task completed.

I'll analyze this GitHub issue and enrich it with relevant codebase information. Let me start by examining the key files mentioned in the issue.

---

View full conversation

Powered by 1Code

[1code-async]

Issue Triage: Codex Tool Approval Pipeline Missing

This is a confirmed architectural gap. The Codex/ACP path does not implement tool permission approval, unlike the Claude path which has a complete approval chain. This issue is a duplicate of #178 (Codex agent gets stuck on permission prompts) and closely related to #193 (no permission settings for Codex).

---

Root Cause Analysis

The issue author's analysis is accurate. There are three missing pieces:

1. Backend: No pendingToolApprovals mechanism for Codex

The Claude router maintains a pendingToolApprovals Map that pauses tool execution until the user responds (src/main/lib/trpc/routers/claude.ts:338-348). It includes a 60-second timeout fallback (claude.ts:1893-1908) and a respondToolApproval tRPC mutation (claude.ts:2875-2896).

The Codex router has none of this. The ACP provider is created with no permission handler:

// codex.ts:1255-1267 — no permission/approval config
const provider = createACPProvider({
  command: resolveCodexAcpBinaryPath(),
  env: buildCodexProviderEnv(params.authConfig),
  authMethodId: getCodexAuthMethodId(params.authConfig),
  session: { cwd: params.cwd, mcpServers: params.mcpServers },
  persistSession: true,
})

Tools are passed directly to streamText with no interception layer (codex.ts:1772):

tools: provider.tools,

2. Frontend Transport: No permission event handling

The ACP chat transport (src/renderer/features/agents/lib/acp-chat-transport.ts:161-243) only handles:

• session-init (line 186)
• auth-error (line 195)
• error (line 232)

Compare with the IPC chat transport for Claude (src/renderer/features/agents/lib/ipc-chat-transport.ts:225-270) which handles:

• ask-user-question → stores in pendingUserQuestionsAtom
• ask-user-question-timeout → moves to expiredUserQuestionsAtom
• ask-user-question-result → stores in askUserQuestionResultsAtom

3. SDK Limitation: @mcpc-tech/acp-ai-provider doesn't expose a permission handler

The ACPProviderSettings type does not include a permission handler callback. When the ACP binary sends a session/request_permission event and no handler is registered, the SDK defaults to auto-selecting the first option — which may not be the intended behavior for escalated permissions. This means even if 1Code wanted to intercept, the current SDK API doesn't support it cleanly.

---

Relevant Files

File	Lines	Role
src/main/lib/trpc/routers/codex.ts	1255-1267, 1772	Provider creation (no approval), tools passed to streamText
src/main/lib/trpc/routers/claude.ts	338-348, 1885-1917, 2875-2896	Reference implementation: pendingToolApprovals, timeout, respondToolApproval
src/renderer/features/agents/lib/acp-chat-transport.ts	161-243	Codex frontend transport (missing permission events)
src/renderer/features/agents/lib/ipc-chat-transport.ts	225-270	Claude frontend transport (has permission events)
src/renderer/features/agents/main/active-chat.tsx	2940-2984	Claude UI: question answer submission + skip

---

Related Issues

• [Bug] Codex agent gets stuck on permission prompts — requests never surface in UI #178 (open) — Same root cause: "Codex agent gets stuck on permission prompts -- requests never surface in UI"
• No option for permission setting (codex) #193 (open) — Related: "No option for permission setting (codex)"
• [CRITICAL] Dangerous permissions bypassed in agent mode #104 (closed) — Previously fixed inverse problem: dangerous permissions bypassed in agent mode

Consider consolidating #178, #193, and #211 into a single tracking issue.

---

Suggested Implementation Approach

Based on the existing Claude approval pattern, the fix would involve:

Backend (codex.ts):

1. Add a pendingToolApprovals Map (mirroring claude.ts:338-348)
2. Intercept tool calls that require escalated permissions before they reach streamText. This likely requires either:
   • A middleware layer between provider.tools and streamText that checks for require_escalated sandbox permissions, or
   • Upstream support in @mcpc-tech/acp-ai-provider to expose a requestPermission callback in ACPProviderSettings
3. Add a respondToolApproval mutation to the Codex tRPC router
4. Add a timeout fallback (e.g., 60s like Claude) that auto-denies and emits a timeout event

Frontend (acp-chat-transport.ts):

1. Handle ask-user-question / permission request chunks (similar to ipc-chat-transport.ts:225-244)
2. Handle timeout chunks
3. Wire up approval/deny responses to the new Codex respondToolApproval mutation

SDK consideration: If @mcpc-tech/acp-ai-provider doesn't expose a permission handler, this may require either:

• A PR to the upstream SDK to add onPermissionRequest to ACPProviderSettings
• A workaround by intercepting the ACP binary's stdout/transport events directly before they reach the SDK

---

This comment was generated by an automated issue enrichment assistant.

[1code-async]

Analysis

This is a confirmed bug. The issue is a duplicate of #178, which describes the same root cause from a different angle. This comment provides a detailed implementation plan based on codebase analysis.

Root Cause

The Codex/ACP provider path has no tool approval chain. When the Codex ACP binary encounters a tool call requiring require_escalated sandbox permissions, there is no handler to surface the approval request to the user, so the stream hangs indefinitely.

Three gaps were identified:

1. Backend — no permission handler registered on the ACP provider

   • createACPProvider() is called at codex.ts:1255-1267 with only command, env, authMethodId, session, and persistSession.
   • No setPermissionRequestHandler() is called after provider creation.
   • The @mcpc-tech/acp-ai-provider SDK defaults to auto-selecting the first option when no handler is registered, but this does not resolve correctly for require_escalated calls — the tool call either silently fails or the process hangs waiting for a response.

2. Backend — no pendingToolApprovals equivalent for Codex

   • streamText() at codex.ts:1764-1774 passes provider.tools directly with no interception layer (no canUseTool equivalent).
   • Compare with Claude's pendingToolApprovals Map at claude.ts:338-348, the canUseTool callback at claude.ts:1884-1917 with 60s timeout, and the respondToolApproval mutation at claude.ts:2875-2896.

3. Frontend — transport ignores permission events

   • acp-chat-transport.ts:161-251 only handles session-init, auth-error, error, and finish chunk types.
   • There is no handling for ask-user-question, ask-user-question-timeout, or any permission request event.
   • Compare with the IPC transport (Claude), which handles all three question/approval chunk types and manages pendingUserQuestionsAtom / expiredUserQuestionsAtom.

Relationship to #178

Issue #178 identified the same root cause (March 2026) and proposed two solution paths. This issue (#211) provides additional evidence from session logs and confirms the bug persists with GPT-5.5.

---

Implementation Plan

Phase 1: Backend — Wire up ACP permission request handler

File: src/main/lib/trpc/routers/codex.ts

1. Add a pendingCodexApprovals Map (similar to pendingToolApprovals in claude.ts):

   const pendingCodexApprovals = new Map<
     string, // requestId
     {
       subChatId: string
       resolve: (decision: { approved: boolean; selectedOptionIndex?: number; message?: string }) => void
     }
   >()

2. Add a clearPendingCodexApprovals() helper that resolves all pending approvals with approved: false for a given subChatId (called during cleanup/abort).

3. Register setPermissionRequestHandler() on the provider after createACPProvider() at line ~1267. The handler should:

   • Generate a unique requestId
   • Emit a new "codex-permission-request" chunk via safeEmit() containing the permission details (command, sandbox level, options)
   • Store a resolver in pendingCodexApprovals
   • Await the Promise with a 60-second timeout (matching Claude's pattern)
   • On timeout, emit a timeout chunk and resolve with approved: false
   • Return the user's decision to the ACP SDK

4. Add a respondCodexApproval tRPC mutation on the Codex router:

   respondCodexApproval: publicProcedure
     .input(z.object({
       requestId: z.string(),
       approved: z.boolean(),
       selectedOptionIndex: z.number().optional(),
       message: z.string().optional(),
     }))
     .mutation(({ input }) => { ... })

5. Hook cleanup into the existing session teardown — when the subscription unsubscribes or the abort controller fires, call clearPendingCodexApprovals().

Phase 2: Frontend Transport — Handle permission chunks

File: src/renderer/features/agents/lib/acp-chat-transport.ts

6. Add handlers for new chunk types in the onData callback (after the existing session-init / auth-error / error handlers):
   • "codex-permission-request" → Store in a new pendingCodexPermissionsAtom (or reuse the existing pendingUserQuestionsAtom if the shape is compatible)
   • "codex-permission-timeout" → Move from pending to expired
   • "codex-permission-result" → Update result atom

Phase 3: Frontend UI — Permission approval dialog

File: src/renderer/features/agents/main/active-chat.tsx + new component

7. Decide whether to reuse the existing AgentUserQuestion component or create a CodexPermissionDialog. The ACP permission request shape (session/request_permission) has a different structure than AskUserQuestion (it has options with labels rather than free-form questions), so a dedicated component is likely cleaner.

8. Add approve/deny handlers in active-chat.tsx that call trpcClient.codex.respondCodexApproval.mutate() (mirroring the pattern at active-chat.tsx:2937-2984).

9. Add state atoms in src/renderer/features/agents/atoms/index.ts:

   export const pendingCodexPermissionsAtom = atom<Map<string, PendingCodexPermission>>(new Map())
   export const expiredCodexPermissionsAtom = atom<Map<string, PendingCodexPermission>>(new Map())

Phase 4: Timeout fallback

10. Add a global timeout guard — if a Codex stream has been in "generating" state for >90 seconds with no new chunks, emit a synthetic error and close the stream. This prevents the UI from being stuck indefinitely regardless of the permission handling (defense in depth).

---

Key Files to Modify

File	Changes
src/main/lib/trpc/routers/codex.ts	Add pendingCodexApprovals, register setPermissionRequestHandler(), add respondCodexApproval mutation, wire cleanup
src/renderer/features/agents/lib/acp-chat-transport.ts	Handle codex-permission-request, codex-permission-timeout, codex-permission-result chunks
src/renderer/features/agents/atoms/index.ts	Add pendingCodexPermissionsAtom, expiredCodexPermissionsAtom
src/renderer/features/agents/main/active-chat.tsx	Add permission dialog rendering + approve/deny handlers for Codex
New: src/renderer/features/agents/ui/codex-permission-dialog.tsx	Permission approval UI component

Upstream Consideration

The @mcpc-tech/acp-ai-provider ACPProviderSettings type does not currently expose a permissionRequestHandler config option — the handler must be set imperatively via setPermissionRequestHandler() after provider creation. If this method is not available on the ACPProvider instance returned by createACPProvider(), the team may need to either:

• Access the underlying ACPAISDKClient to call setPermissionRequestHandler(), or
• Open an upstream issue/PR on @mcpc-tech/acp-ai-provider to support a handler in the config object.

This should be verified first before starting implementation.

[1code-async]

Issue Enrichment — Codebase Analysis

Likely Duplicate

This issue closely matches #178 ("[Bug] Codex agent gets stuck on permission prompts — requests never surface in UI"), which was opened on 2026-03-04 and remains open. Both issues describe the same root cause: Codex tool calls requiring user approval hang indefinitely because no permission handler is wired up. This issue (#211) provides additional detail around the require_escalated sandbox permission path specifically.

---

Confirmed Root Cause — Code Evidence

The issue reporter's analysis is accurate. Here are the exact code locations:

1. No permission handler in Codex ACP provider creation

src/main/lib/trpc/routers/codex.ts:1255-1267 — createACPProvider() is called with only command, env, authMethodId, session, and persistSession. No permission/approval handler is configured:

const provider = createACPProvider({
  command: resolveCodexAcpBinaryPath(),
  env: buildCodexProviderEnv(params.authConfig),
  authMethodId: getCodexAuthMethodId(params.authConfig),
  session: { cwd: params.cwd, mcpServers: params.mcpServers },
  persistSession: true,
})

2. Tools passed directly to streamText with no approval middleware

src/main/lib/trpc/routers/codex.ts:1764-1774 — provider.tools is handed straight to streamText() without any interception layer:

const result = streamText({
  model: provider.languageModel(selectedModelId),
  messages: [...],
  tools: provider.tools,
  abortSignal: abortController.signal,
})

3. Frontend transport only handles 4 event types

src/renderer/features/agents/lib/acp-chat-transport.ts:161-251 — The onData handler processes session-init, auth-error, error, and finish only. No handling for permission request events.

4. No setPermissionRequestHandler call anywhere in the codebase

A full codebase search for setPermissionRequestHandler and request_permission returns zero results in application code (only in use-desktop-notifications.ts for browser notification permissions, which is unrelated).

---

Comparison: How Claude Handles This

The Claude path has a complete tool approval pipeline that Codex lacks:

Component	Claude	Codex
Pending approvals store	pendingToolApprovals Map (claude.ts:338-348)	None
UI emission	Emits ask-user-question event (claude.ts:1887-1891)	None
Timeout handling	60s timeout with ask-user-question-timeout event (claude.ts:1899-1908)	None
Response mutation	respondToolApproval tRPC mutation (claude.ts:2875-2896)	None
Frontend callback	Calls trpcClient.claude.respondToolApproval.mutate() (active-chat.tsx:2947)	None
Cleanup on cancel	clearPendingApprovals() auto-rejects (claude.ts:352-358)	None

---

Suggested Implementation Approach

Based on the existing Claude implementation, here are the specific files that need changes:

Backend (src/main/lib/trpc/routers/codex.ts):

1. Add a pendingCodexToolApprovals Map (mirror claude.ts:338-348)
2. After createACPProvider() at line 1267, call provider.setPermissionRequestHandler() to register a handler that emits permission request events via the tRPC subscription and waits on a Promise (mirror claude.ts:1893-1917)
3. Add a respondCodexToolApproval mutation (mirror claude.ts:2875-2896)
4. Add clearPendingCodexApprovals() in the cleanup/cancel paths (mirror claude.ts:352-358)
5. Add a timeout (e.g., 60s) to auto-reject stale approval requests

Frontend transport (src/renderer/features/agents/lib/acp-chat-transport.ts):

1. Handle new event types in onData: permission-request, permission-timeout
2. Surface these to the UI state (e.g., via a new Jotai atom similar to pendingUserQuestionsAtom)

Frontend UI (src/renderer/features/agents/main/active-chat.tsx):

1. Add permission approval dialog for Codex (can reuse patterns from the Claude ask-user-question flow at lines 2947-3029)
2. Call the new respondCodexToolApproval mutation on user action

Quick workaround alternative: If the ACP SDK supports an auto-approve configuration or full-auto mode flag, passing it in createACPProvider() at line 1255 would immediately unblock users — similar to how Claude uses allowDangerouslySkipPermissions: true in agent mode.

---

Related Issues

• [Bug] Codex agent gets stuck on permission prompts — requests never surface in UI #178 — Same root cause, still open. Consider closing one as duplicate.
• [CRITICAL] Dangerous permissions bypassed in agent mode #104 (closed) — "[CRITICAL] Dangerous permissions bypassed in agent mode" — discusses the Claude-side allowDangerouslySkipPermissions approach, relevant context for deciding between proper approval UI vs auto-approve for Codex.