Skip to content

Codex app composer sometimes does not focus after clicking input #28872

Open
Open
Codex app composer sometimes does not focus after clicking input#28872
Labels
appIssues related to the Codex desktop appbugSomething isn't working

Description

@yangwei2future
yangwei2future
opened on Jun 18, 2026

What happened?

In the Codex desktop app on macOS, the chat composer sometimes does not receive focus after clicking the input area. The click appears to land on the composer area, but the editor is not focused and typing does not enter text. After switching UI state or waiting for a while, the composer may start working again.

This feels like a UI/focus bug in the desktop app rather than a project-specific issue.

Reproduction / observed sequence

I do not yet have a minimal deterministic repro, but it seems correlated with interacting with file/resource previews, the browser/sidebar area, or floating UI panels before returning to the chat composer.

Observed locally from Codex app Sentry breadcrumbs:

  • Around 2026-06-18 14:21:27 to 14:23:14 CST, there were multiple ui.click events on div.ProseMirror.
  • During those clicks, there were no corresponding div.ProseMirror.ProseMirror-focused or ui.input events.
  • Later, the same composer area became div.ProseMirror.ProseMirror-focused and input events resumed.

This matches the visible behavior: clicking the composer looks like it should focus the editor, but nothing happens until the app state changes.

Expected behavior

Clicking the chat composer should consistently focus the editor unless an explicit modal or disabled state is active.

Environment

  • Codex app version: 26.611.62324
  • Electron/Chrome runtime: 149.0.7827.115
  • macOS: 26.2
  • Locale/timezone observed: zh-CN / Asia/Shanghai

Additional context

Local process/log inspection did not show a clear JavaScript exception at the time of the issue. It looks more like a stale overlay, side panel, browser/resource preview, or focus trap intercepting the focus transition.

A possibly related warning appeared near other UI interactions:

Warning: Missing `Description` or `aria-describedby={undefined}` for {DialogContent}.

Happy to provide more logs or a session ID if helpful.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    on Jun 18, 2026

  2. github-actions commented on Jun 18, 2026

    @github-actions
    github-actionsBot
    on Jun 18, 2026 – with GitHub Actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  3. Pybsama commented on Jun 19, 2026

    @Pybsama
    Pybsama
    on Jun 19, 2026

    I am seeing what looks like the same issue on macOS, with one additional data point.

    Environment:

    • Codex desktop app version: 26.616.32156
    • Bundled Codex CLI: 0.142.0-alpha.1
    • Platform: macOS arm64
    • OS language: zh-Hans-HK
    • This also happened on the earlier observed app version 26.611.62324 / CLI 0.140.0-alpha.19.

    Visible behavior:

    • After switching away from Codex and returning, clicking the chat composer did not show a cursor.
    • Typing from the physical Mac keyboard was not possible.
    • I could still continue the conversation from another device.
    • Bringing the app to the foreground did not fully resolve it.
    • Pressing Cmd+R to refresh the Codex desktop window restored composer focus, so this looks like a renderer/document focus state problem rather than an auth, thread, or install issue.

    Diagnostics:

    • codex doctor --summary --no-color --ascii reported install, auth, config, local state DBs, Git, search, and thread inventory as OK.
    • It also reported WebSocket/reachability and TERM=dumb warnings in the sandboxed diagnostic environment, but those do not appear to explain the local desktop composer focus failure.

    Relevant app log excerpt from the recurrence:

    2026-06-19T11:55:37.780Z error [electron-message-handler] [desktop-notifications][unhandled-rejection] NotAllowedError: Failed to execute 'writeText' on 'Clipboard': Document is not focused.
    at de (app://-/assets/user-message-attachments-DuyCYP_s.js:1:15327)
    at bd (app://-/assets/client-C1mrATqU.js:8:125889)
    at app://-/assets/client-C1mrATqU.js:8:130882

    Around the same time, the app log also repeatedly included:

    Item not found in turn state
Dropping commandExecution/outputDelta for missing item

    The useful workaround so far is Cmd+R in the Codex desktop app, which is much less disruptive than quitting and reopening the app.

  4. JieweiYan commented on Jun 23, 2026

    @JieweiYan
    JieweiYan
    on Jun 23, 2026

    I am seeing the same composer focus failure on macOS, with additional desktop logs that point to stale browser sidebar / IAB route state and unknown conversation state.

    Environment:

    Codex App: 26.616.71553 (CFBundleVersion 4265)
Bundled app CLI: codex-cli 0.142.0
Codex primary runtime selected by app logs: 26.622.11653
Platform: Darwin 25.5.0 arm64 arm
macOS: 26.5.1

    Observed behavior:

    • After switching away from Codex App and then switching back, the composer visually appears available but cannot be focused.
    • Clicking the composer does not put the caret there, and typing does not enter text.
    • The freeze has lasted from around 1 minute to 10+ minutes. Reload/restart usually recovers the current occurrence.
    • This has happened repeatedly across multiple threads.

    The strongest local log signatures around the incidents are:

    error [electron-message-handler] Received item/started for unknown conversation conversationId=...
error [electron-message-handler] Received item/completed for unknown conversation conversationId=...
error [electron-message-handler] Conversation state not found conversationId=...
error [electron-message-handler] Received turn/started for unknown conversation conversationId=...
error [electron-message-handler] Received turn/completed for unknown conversation conversationId=...

    IAB/browser sidebar related signatures:

    info [electron-message-handler] IAB_LIFECYCLE received browser sidebar owner sync ...
info [browser-session-registry] IAB_LIFECYCLE rebound browser sidebar window ...
info [browser-session-registry] IAB_LIFECYCLE reassigned browser use route sourceConversationId=... targetConversationId=client-new-thread:...
warning [browser-sidebar-manager] IAB_LIFECYCLE route window is not live hasWindowState=false ownerDestroyed=null windowDestroyed=null windowId=1
warning [browser-sidebar-manager] IAB_LIFECYCLE browser use route window missing for cursor state conversationId=... windowId=1
warning [browser-sidebar-manager] IAB_LIFECYCLE browser use route window missing for active state conversationId=... windowId=1
warning [browser-use-iab-api] IAB_LIFECYCLE iab backend info request failed ... "No Codex browser route is available for browser session ..."

    During reload/restart recovery I also saw:

    warning [IpcRouter] Socket error errorCode=EPIPE errorMessage="write EPIPE"
info [AppServerConnection] Stopping app-server transport connectionId=1 transport=stdio

    Slow status calls are frequently present during stuck periods:

    method=mcpServerStatus/list ... durationMs=8585
method=mcpServerStatus/list ... durationMs=8782
method=mcpServerStatus/list ... durationMs=10857
method=mcpServerStatus/list ... durationMs=15242

    There was also a separate latency amplifier in my setup: the app auto-connected to a remote SSH app-server host with an old codex version:

    app_server_connection.transport_connect_failed errorMessage=codex-app-server-version-unsupported:0.139.0 ... transport=websocket
Request failed ... durationMs=10622 ... method=remoteControl/status/read ... "codex-app-server-version-unsupported:0.139.0"
Request failed ... durationMs=14036 ... method=remoteControl/status/read ... "codex-app-server-version-unsupported:0.139.0"
Request failed ... durationMs=13028 ... method=thread/list ... "codex-app-server-version-unsupported:0.139.0"

    I upgraded that remote host to codex-cli 0.142.0, which should remove one amplifier, but the focus/freeze issue predates that and appears tied to desktop renderer state restoration.

    Local mitigations tried:

    • SQLite checkpoint/VACUUM on local Codex logs DB reduced DB size but did not stop the issue.
    • Reloading/restarting Codex App recovers individual occurrences but does not prevent recurrence.
    • Disabling bundled Browser/Chrome/Computer Use plugins is not a viable workaround: Codex App still tried to restore/bind browser sidebar state and startup became abnormal with route window is not live / browser use route window missing errors. Re-enabling those plugins restored normal startup.

    Hypothesis from the available logs:

    This looks like a Codex App frontend state restoration bug involving browser sidebar / IAB route state and conversation registry state. Slow MCP/remote app-server calls can amplify the user-visible freeze, but the most specific failure signatures are stale browser route/window state and notifications for unknown/missing conversation state.

    Possibly related issues:

  5. onlyLTY commented on Jul 14, 2026

    @onlyLTY
    onlyLTY
    on Jul 14, 2026

    I encountered the same problem as well.

  6. Pybsama commented on Jul 14, 2026

    @Pybsama
    Pybsama
    on Jul 14, 2026 via email

  7. Pybsama commented on Jul 14, 2026

    @Pybsama
    Pybsama
    on Jul 14, 2026 via email

  8. chesongling123 commented on Jul 16, 2026

    @chesongling123
    chesongling123
    on Jul 16, 2026 – with ChatGPT Codex Connector

    I can confirm the same issue on macOS in a newer build, with a slightly different (and more severe) visible symptom.

    Environment:

    • Codex desktop app: 26.707.91948
    • macOS Apple Silicon / arm64
    • Locale: zh-CN

    Observed behavior:

    • Clicking the composer does not produce a visible caret.
    • Keyboard events still appear to be accepted, but the typed characters are not rendered in the composer at all.
    • Text selection/clicking inside the composer also does not restore the caret.
    • Fully quitting and reopening the ChatGPT/Codex app reliably restores normal behavior for that occurrence.

    This is therefore not only a failure to focus: the composer can enter a broken input/render state where it appears empty despite typing.

    My local desktop logs during the affected app session also contain repeated, redacted variants of:

    error [electron-message-handler] Received turn/started for unknown conversation conversationId=...
error [electron-message-handler] Received turn/completed for unknown conversation conversationId=...
info [browser-session-registry] IAB_LIFECYCLE reassigned browser use route ... targetConversationId=client-new-thread:...

    I cannot prove these logs are the root cause, but they match the stale conversation/browser-route state already reported above. I did not include full logs because they can contain thread and workspace metadata.

    I have not yet isolated whether Codex Pet is enabled at the time of failure.

  9. Pybsama commented on Jul 16, 2026

    @Pybsama
    Pybsama
    on Jul 16, 2026 via email
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions