[Bug] Codex Desktop in-app browser annotations lose focus when pressing Space

Open 💬 3 comments Opened Jun 4, 2026 by uatragada

Summary

The Codex Desktop in-app browser annotation flow appears to have regressed on Windows. While typing in an annotation, pressing Space scrolls the underlying webpage and can pull focus out of the annotation editor. The user also reports that adding multiple annotations no longer works as it did previously.

This looks like a focus or keyboard event propagation issue in the in-app browser annotation/comment overlay. Space should be handled by the annotation text input, not by the page behind it.

Environment

  • Platform: Windows
  • Codex Desktop package observed: OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0
  • Runtime: Owl / Electron shell
  • Chromium version observed in process annotations: 148.0.7778.179
  • Date observed: 2026-06-03

Reproduction steps

  1. Open Codex Desktop on Windows.
  2. Open a local or remote page in the Codex in-app browser.
  3. Enable Annotation mode.
  4. Select an element or area on the page.
  5. Start typing an annotation.
  6. Press Space while typing.

Expected behavior

  • Space inserts a space character into the annotation text field.
  • Focus remains inside the annotation editor.
  • The underlying page does not scroll.
  • The user can continue adding multiple annotations before sending the message.

Actual behavior

  • Pressing Space scrolls the underlying webpage.
  • Focus appears to leave the annotation editor or annotation flow.
  • The user is no longer able to add multiple annotations like before.

Local diagnostics

The installed app is running from:

C:\Program Files\WindowsApps\OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0\app\Codex.exe

The packaged app contains an annotation/comment preload bundle:

C:\Program Files\WindowsApps\OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0\app\resources\app.asar
  .vite/build/comment-preload.js

String-level inspection of the page-side annotation runtime shows handling for annotation runtime messages such as:

browser-sidebar-runtime-open-editor
browser-sidebar-runtime-close-editor
browser-sidebar-runtime-focus-editor
browser-sidebar-runtime-exit-comment-mode

The injected page-side keyboard handler appears to special-case Escape and Alt, but no similar guard was visible for Space while an editor is active. That is consistent with the observed behavior where Space reaches the underlying page and triggers scrolling.

The host-side bundle also shows that exiting comment mode sends pending annotations to the composer through an addAnnotationsToComposer path. If focus leaves the editor incorrectly, that may explain why multiple annotations no longer behave as expected.

Suspected root cause

Likely a regression in the annotation editor or injected in-app browser comment overlay where keyboard events from the annotation text field are not being stopped or focus is not being retained.

The Space key should be captured by the editor when a text input, textarea, or contenteditable annotation field is active. It should not bubble to the page or browser shell.

Temporary workaround

  1. Type the annotation in another text field or editor.
  2. Paste the completed text into the annotation box.
  3. Submit the annotation without pressing Space inside the annotation editor.

Suggested engineering checks

  • Ensure the annotation editor receives focus immediately after opening.
  • Ensure Space is not interpreted by the page when the annotation input is focused.
  • Ensure keydown/keypress/keyup events from annotation text inputs stop propagation where appropriate.
  • Re-test multiple annotations in one browser annotation session.
  • Include regression coverage for Space, Enter, Escape, and multiple annotation creation.

References

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗