Codex "Apps" permission requests map to requestType unknown outside Auto mode, hiding the approval UI

[saiyalamarty]

What happened

When using Codex with an "App"/connector attached (e.g. a GitHub app) in Auto-accept edits or Full access runtime mode, the app's permission request (e.g. for GitHub access) never shows an approval prompt. The tool call just stalls. Switching the thread to Auto mode makes the same kind of request work fine.

Diagnosis

Codex Apps request elevated permissions via the JSON-RPC method item/permissions/requestApproval (confirmed present in packages/effect-codex-app-server/src/_generated/schema.gen.ts:36111). toRequestTypeFromMethod in apps/server/src/provider/Layers/CodexAdapter.ts (~line 297) only maps:

• item/commandExecution/requestApproval -> command_execution_approval
• item/fileRead/requestApproval -> file_read_approval
• item/fileChange/requestApproval -> file_change_approval
• applyPatchApproval -> apply_patch_approval
• execCommandApproval -> exec_command_approval
• item/tool/requestUserInput -> tool_user_input
• item/tool/call -> dynamic_tool_call
• account/chatgptAuthTokens/refresh -> auth_tokens_refresh

item/permissions/requestApproval is not in this list, so it falls through to default: return "unknown".

On the client, apps/web/src/session-logic.ts defines PendingApproval.requestKind as exactly "command" | "file-read" | "file-change" (line 112), and requestKindFromRequestType (line 370) returns null for anything not in that set, including "unknown". derivePendingApprovals then never inserts the request into openByRequestId, so no approval card is ever rendered. This is the same failure pattern as #4795 (OpenCode skill/other permission kinds mapping to unknown), but for a different provider and a different missing case — hence a separate issue.

This explains why the same class of request behaves differently by runtime mode: runtimeModeToThreadConfig in apps/server/src/provider/Layers/CodexSessionRuntime.ts (~line 265) sets approvalsReviewer: "auto_review" only for "auto" mode; "auto-accept-edits", "approval-required", and "full-access" all set approvalsReviewer: "user". With auto_review, Codex resolves the permission request itself without needing T3's UI, so the missing mapping never matters. With user, Codex is waiting on a human decision that T3 never surfaces, so the request just hangs.

Likely compounding effect (not independently verified against a live thread): stopSessionInternal in CodexAdapter.ts (~line 1928) tears down a session's runtime/scope/event fiber but never resolves any still-open approval requests, unlike CursorAdapter/GrokAdapter, which call settlePendingApprovalsAsCancelled on teardown. If that holds, stopping a thread stuck this way would leave it permanently unsettleable, the Codex counterpart to #7113.

Steps to reproduce

1. Attach a Codex "App"/connector that requires a permission grant (e.g. GitHub) to a thread.
2. Set the thread's runtime mode to "Auto-accept edits" or "Full access".
3. Prompt the agent to use the app in a way that triggers a permission check (e.g. a GitHub-scoped action).
4. Codex emits item/permissions/requestApproval; T3 maps it to requestType: "unknown"; no approval UI appears; the tool call stalls with nothing for the user to act on.
5. Switching the same thread to "Auto" mode and repeating the same app action works, because Codex's auto_review reviewer resolves the request itself.

Version

0.0.34-nightly.20260821.1151

Environment

macOS darwin arm64 (25.6.0), T3 Code desktop app (Nightly), Node v24.19.0

Evidence

Source-grounded, not captured from a live thread (none was available at triage time):

• apps/server/src/provider/Layers/CodexAdapter.ts:297-318 — toRequestTypeFromMethod, missing item/permissions/requestApproval case
• packages/effect-codex-app-server/src/_generated/schema.gen.ts:36111 — item/permissions/requestApproval method literal
• apps/web/src/session-logic.ts:110-115,370-384 — PendingApproval.requestKind union and requestKindFromRequestType default-null
• apps/server/src/provider/Layers/CodexSessionRuntime.ts:265-298 — runtimeModeToThreadConfig, approvalsReviewer differs only for "auto"
• apps/server/src/provider/Layers/CodexAdapter.ts:1928-1939 — stopSessionInternal, no approval settlement on teardown

Related issues

• [Bug] T3 Code silently drops OpenCode skill permission requests — approval never shown, turn aborts #4795 — same failure pattern (requestType: "unknown" hides the approval UI), but for OpenCode's skill permission kind. This issue is not a duplicate: different provider (Codex), different missing method (item/permissions/requestApproval vs OpenCode's non-bash/read/edit permission kinds).
• [Bug]: OpenCodeAdapter leaks pending permission requests on session teardown — thread becomes permanently unsettleable #7113 — OpenCodeAdapter leaks pending approvals on teardown, making the thread permanently unsettleable. Flagged above as a plausible Codex-side parity gap in stopSessionInternal, not independently confirmed here.

Fix applied or workaround

None applied — no live thread was available to fix. Workaround: use "Auto" runtime mode for Codex threads that use Apps/connectors, since that is the only mode where approvalsReviewer is auto_review rather than user.

Filed by

claude (opus-5) via t3 triage