Codex app composer sometimes does not focus after clicking input
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.clickevents ondiv.ProseMirror. - During those clicks, there were no corresponding
div.ProseMirror.ProseMirror-focusedorui.inputevents. - Later, the same composer area became
div.ProseMirror.ProseMirror-focusedand 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.
8 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I am seeing what looks like the same issue on macOS, with one additional data point.
Environment:
26.616.321560.142.0-alpha.1zh-Hans-HK26.611.62324/ CLI0.140.0-alpha.19.Visible behavior:
Cmd+Rto 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 --asciireported install, auth, config, local state DBs, Git, search, and thread inventory as OK.TERM=dumbwarnings 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:
Around the same time, the app log also repeatedly included:
The useful workaround so far is
Cmd+Rin the Codex desktop app, which is much less disruptive than quitting and reopening the app.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:
Observed behavior:
The strongest local log signatures around the incidents are:
IAB/browser sidebar related signatures:
During reload/restart recovery I also saw:
Slow status calls are frequently present during stuck periods:
There was also a separate latency amplifier in my setup: the app auto-connected to a remote SSH app-server host with an old
codexversion: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:
route window is not live/browser use route window missingerrors. 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:
unknown conversationlogsturn/started for unknown conversationroute window is not live/No Codex browser route is availableI encountered the same problem as well.
Thanks for the detailed logs. I believe this issue is actually related to
Codex Pet.
In my testing, the composer focus problem occurs when Codex Pet is enabled.
After disabling Codex Pet, I can no longer reproduce the issue.
Could you try turning off Codex Pet and see whether the problem disappears
for you as well? This may help confirm whether it is the same root cause.
On Tue, 14 Jul 2026 at 18:26, 唯依 @.***> wrote:
Thanks for the detailed logs. I believe this issue is actually related to
Codex Pet.
In my testing, the composer focus problem occurs when Codex Pet is enabled.
After disabling Codex Pet, I can no longer reproduce the issue.
Could you try turning off Codex Pet and see whether the problem disappears
for you as well? This may help confirm whether it is the same root cause.
On Tue, 23 Jun 2026 at 19:19, JieweiYan @.***> wrote:
I can confirm the same issue on macOS in a newer build, with a slightly different (and more severe) visible symptom.
Environment:
26.707.91948Observed behavior:
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:
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.
But after I close Codex Pet，it become normal.
On Thu, 16 Jul 2026 at 22:31, chesongling123 @.***>
wrote: