[Windows][Chrome side panel] request_permissions card flashes and disappears after reopening the side panel

What issue are you seeing?

Environment

• Windows package: OpenAI.Codex_26.825.5331.0_x64
• Bundled CLI reported by the affected session: 0.151.0-alpha.7.1
• Bundled Chrome plugin: 26.825.41651
• ChatGPT Chrome extension: 1.2.27268.51612 (Manifest V3)
• Google Chrome: 151.0.7922.174
• Windows x64, version 25H2, build 26200.9278 (registry edition: Home/Core)

Problem

In a thread running inside the ChatGPT/Codex Chrome extension side panel, a filesystem permission request blocks forever because the approval card is not usable.

The agent calls request_permissions for a specific directory outside the current workspace. No approval card remains visible. If the Chrome side panel is closed and reopened, the card flashes for a fraction of a second and immediately disappears. The user therefore cannot approve or reject the request, and the tool call never receives a result.

This is not a website-origin permission prompt. The affected call is a Codex filesystem permission request similar to:

request_permissions({
  permissions: {
    file_system: {
      write: ["%USERPROFILE%\\.codex\\memories\\extensions\\ad_hoc\\notes"]
    }
  }
})

The active policy allowed request_permissions and MCP elicitations. The requested directory was correctly outside the thread's writable workspace, so showing an approval UI was expected.

Actual behavior

• The card is absent during the initial request or is not interactable.
• After reopening the side panel, it flashes briefly and disappears.
• The session remains blocked with no approval or denial result.
• Retrying from another side-panel thread produces the same deadlock.

What steps can reproduce the bug?

1. On Windows, open a Codex thread in the ChatGPT Chrome extension side panel.
2. Use a projectless/workspace-restricted thread whose writable roots do not include %USERPROFILE%\\.codex.
3. Ask Codex to perform a legitimate write under %USERPROFILE%\\.codex, so it calls request_permissions with a narrow file_system.write request.
4. Observe that the thread becomes blocked and no stable approval card is available.
5. Close the Chrome side panel.
6. Reopen the side panel.
7. Observe that the pending permission card flashes briefly and then disappears.
8. Return to the affected thread or wait: the request remains unresolved and the task never continues.

The behavior reproduced on two permission attempts in side-panel threads on the same machine.

What is the expected behavior?

• The approval card should stay visible until the user explicitly approves or rejects it.
• Closing and reopening the side panel should rehydrate the pending approval for the same thread.
• If the side panel cannot restore the request, Codex should cancel it with a visible error instead of leaving the tool call pending forever.
• A pending approval should be discoverable from the thread UI after reopening the panel.

Additional information

Sanitized local evidence

The affected JSONL session records a completed custom_tool_call containing tools.request_permissions(...) at 2026-08-30T11:00:25.352Z. The file ends immediately after that record:

permission tool call ordinal: 202
matching custom_tool_call_output: none
subsequent session events: 0

The session metadata identifies the originator as:

codex-chrome-extension-sidepanel

The user then reopened the side panel, where the pending card was visible only momentarily.

User impact

Any side-panel task that legitimately requires an additional filesystem or network grant can become permanently stuck. The user cannot complete, reject, or recover the request from the Chrome extension UI.

Possible area to inspect

This looks like pending-elicitation state being present briefly during side-panel hydration, followed by a route/thread-state transition that removes the approval component without resolving the backend request. Please verify that pending request_permissions elicitations are keyed and restored using the canonical thread ID across side-panel close/reopen and temporary-to-persisted thread transitions.

Related reports (similar approval-state failures, not exact duplicates)

• https://github.com/openai/codex/issues/22308 — an approval UI action dismisses without resolving the request.
• https://github.com/openai/codex/issues/22019 — a Windows approval flow is suppressed and misinterpreted as a denial.
• https://github.com/openai/codex/issues/11482 — approval UI state can leave a thread stuck.

Raw local logs contain thread and call identifiers and can be provided privately to maintainers if needed.

Start by tracing pending request_permissions elicitations through side-panel hydration and the temporary-to-persisted thread transition. Check how pending state is keyed across close and reopen, especially when the canonical thread ID changes. Done means the approval remains discoverable until approval or rejection, or a visible cancellation error resolves the blocked tool call.