›_ Codex Issues
Codex Issues / #33323

Codex Desktop auto-switches to inactive task when it requests approval

Open 💬 2 comments Opened Jul 15, 2026 by claell

What version of the Codex App are you using (From "About Codex" dialog)?

Codex Desktop on Windows, Microsoft Store/AppX package:

  • OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0

What subscription do you have?

Unknown / not relevant.

What platform is your computer?

Windows, x64. Local OS version: Microsoft Windows NT 10.0.26200, build 26200.8655, Education edition (25H2).

What issue are you seeing?

When several tasks are running in parallel in Codex Desktop, an inactive task that reaches a command or permission approval can automatically become the active task. The app navigates away from the task I am currently viewing without an explicit click or keyboard navigation action.

This has occurred repeatedly while I was already working in another task, including while entering text in that task's composer. The task requesting approval suddenly replaces the current task and its approval UI receives attention. There is no advance notification or other transition that lets me choose whether to leave the current task.

I may also have used Ctrl+Tab to move between tasks shortly before some occurrences, but I have not confirmed whether Ctrl+Tab is required to trigger the behavior. The consistent condition is that multiple tasks are active and a task other than the one being viewed requests permission.

This makes parallel task work unpredictable and can interrupt in-progress text entry. Permission requests should be surfaced as attention state, not take over the active task automatically.

What steps can reproduce the bug?

  1. Open several tasks in Codex Desktop on Windows.
  2. Start work in at least two tasks and let them run concurrently with Ask for approval enabled.
  3. Navigate to task A and begin reading its output or typing a message in its composer.
  4. Let task B, which is not currently selected, reach a command or permission request.
  5. Observe that Codex Desktop can automatically navigate from task A to task B and show/focus task B's approval request, without an explicit navigation action.

The behavior is intermittent but recurring. Cycling among tasks with Ctrl+Tab may be a contributing condition, but that correlation is not yet confirmed.

What is the expected behavior?

An approval request from an inactive task should not change the active task or interrupt the composer currently in use.

Codex Desktop should instead surface the pending request through its existing attention mechanisms, such as a sidebar badge, task-switcher indicator, pet state, or permission notification. The user should navigate to the requesting task explicitly, for example by selecting it or activating a notification.

If automatic navigation is intentional, it should at minimum be opt-in and must not occur while the current composer has an in-progress draft.

Additional information

The current Codex documentation describes permission and question notifications as separately configurable attention mechanisms, but I found no documentation stating that an inactive task should automatically replace the active task when it requests approval.

I searched existing openai/codex issues and did not find an exact duplicate. Related but distinct reports include:

  • #31801: CLI/TUI prompts can steal in-progress typing, but this report concerns cross-task navigation in the desktop app.
  • #20817: asks to make tasks awaiting approval easier to find in the desktop sidebar, rather than automatically switching to them.
  • #29008: asks for native permission notifications on macOS; it likewise treats navigation to the requesting task as an explicit notification action.
  • #19876: concerns clicking an approval notification opening the wrong/blank route, not unsolicited navigation while already using another task.

View original on GitHub ↗

2 Comments

claell · 1 month ago

Escalation: Codex can also take Windows foreground focus from another app

This reproduced in a more severe form today on a newer Codex Desktop build:

  • OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0

I was actively using Firefox, with the Firefox window in the foreground and Codex behind it. Without me clicking Codex, selecting a Codex notification, or intentionally switching applications, the Codex window suddenly came to the front.

This is a separate focus boundary from the original report:

  • The original behavior still occurs: while I am inside Codex, a task needing attention can replace the Codex task I am currently using.
  • In this new occurrence, Codex raised its entire application window above Firefox and took Windows foreground focus.

Taking foreground focus from an unrelated application is particularly disruptive and potentially unsafe. It can interrupt scrolling or redirect keyboard input while I am typing in another application. A background task or approval request must not programmatically activate Codex or change the operating-system foreground window.

I did not capture the exact event sequence that triggered this occurrence. It appeared while I had multiple Codex tasks running, consistent with the approval/attention scenario in the original report, but I cannot yet prove which task state change caused the foreground activation.

One possible condition is the Codex window state:

  • When Codex was open behind Firefox, it surfaced to the foreground.
  • I have the impression that fully minimizing Codex may prevent it from surfacing, but this is not yet confirmed.

Expected behavior:

  • If a background Codex task needs approval or input, Codex should show a Windows notification, taskbar badge/flash, or in-app attention indicator.
  • Codex should enter the foreground only after an explicit user action, such as clicking the notification, taskbar icon, or Codex window.
  • The current foreground application and its keyboard input must remain undisturbed.
claell · 1 month ago

Possible correlation with the “Initialize Windows app inspection” timeline action

I found a more precise diagnostic lead in a recent local session. The task timeline showed a separate action with its own tool icon and the title:

Initialize Windows app inspection

This was not a normal user-initiated Computer Use task:

  • I did not invoke @Computer or ask Codex to control the desktop.
  • No Computer Use app-permission request was shown.
  • The timeline action appeared to initialize inspection and retrieve application information.

The local session record confirms that the item was a node_repl/js tool call. Its code loaded the bundled computer-use-client runtime, called setupComputerUseRuntime(...), and retrieved the @oai/sky guidance and confirmation metadata. It was immediately followed by a separate app-discovery call using sky.list_apps().

Candidate session details for correlation:

  • Session ID: 019f9908-665d-71d2-9082-22147c5de31c
  • Inspection initialization timestamp: 2026-07-25T12:02:48.109Z
  • Installed app: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
  • Bundled Computer Use plugin path identified in the call: computer-use/26.721.41059

There is no approval or permission event in the immediate recorded sequence around the initialization and app-discovery calls.

I cannot confirm that this exact call caused the foreground activation, only that the timing in at least one recent session made it appear related. It would be useful to correlate this event with:

  • Codex/Electron window show, focus, or foreground-activation requests;
  • Windows app-inspection runtime initialization;
  • sky.list_apps() or subsequent inspection calls;
  • active-task navigation changes; and
  • any short-lived console child becoming foreground.

Although the runtime is internally shared with Computer Use, this did not present as an explicit Computer Use run. A metadata-only inspection/bootstrap action should not raise Codex over another application or redirect foreground input.

Adjacent reports #23892 and #34266 cover console children stealing focus. I saw the Codex application itself come to the front, so this may be a different path.

@etraut-openai, could you help route this to the relevant Windows Desktop / app-inspection owner? You handled the recent initialization regression affecting this same Windows app-inspection runtime in #29205.