Repository navigation
Linux Desktop: inactive-window resume guard floods journal with 442–572 info messages/sec #51888
Description
Summary
Codex Desktop on Linux repeatedly writes the same informational message to the system journal at roughly 442–572 entries per second:
[electron-message-handler] maybe_resume_skipped_inactive_hotkey_window
This looks like a repeatedly triggered inactive-window resume guard. I could not find an existing issue with this exact message.
Environment
- Ubuntu Linux
- Desktop package: 26.1002.52244
- Bundled CLI: 0.162.0-alpha.2
- Journal application identifier: chatgpt.desktop
- No explicit logging/debug flags on the desktop process
Observed behavior
Four separate, complete 10-second journal samples across approximately 15 minutes measured:
| Sample | Entries per second | Share containing the repeated message |
|---|---|---|
| 1 | 442.1 | 99.8% |
| 2 | 571.7 | 98.5% |
| 3 | 559.9 | 99.8% |
| 4 | 571.8 | 98.9% |
All entries in these windows were informational priority. Another sample contained 4,941 repetitions for the same conversation and renderer window.
The repeated messages reported this generic window state:
documentVisibilityState=visible
rendererWindowAppearance=primary
rendererWindowFocused=false
rendererWindowVisible=false
hostId=local
Conversation identifiers and route values are intentionally omitted.
Read-only inspection of the packaged JavaScript places this message in the resume/stream-ownership guard. It logs and returns status: not-ready, reason: inactive-window when there is no stream role and the window cannot acquire the conversation stream. This suggests repeated triggering of the guard; the underlying trigger is not yet established.
Impact
The sampled message-text rate was approximately 142–184 KB/sec. That would be around 12–16 GB/day if sustained continuously, but this is an extrapolation, not measured journal disk growth. Compression, metadata, allocation and rotation affect actual usage.
The journal occupied several GB. A journal cleanup freed space, but did not stop the repeated messages. CPU impact from this specific logging loop has not been isolated from other application activity.
Reproduction status
Observed repeatedly in a running desktop session. I do not yet have a minimal reproduction or a verified action that starts the loop. The hidden/unfocused state above comes from the logs; no conclusion is being made about which window interaction caused it.
Expected behavior
An inactive-window resume check should not repeatedly emit hundreds of identical informational messages per second for the same conversation. Please investigate whether this path is being retriggered without an appropriate wait/backoff, and whether repeated skip messages should be deduplicated or rate-limited.
Related issues
- [Windows][App][Chrome] Same conversation enters ~22 Hz active-writer retry loop across desktop and Chrome side panel #38560: ownership/resume retry loop with active-writer errors
- [macOS] Archived-thread resume loop (~37 failures/s) precedes recurring CrBrowserMain SIGTRAP crashes #51087: hidden archived-thread resume loop
- [Windows][26.814.5167.0] Hidden avatarOverlay owns completed thread; primary UI stays "Thinking" #39178: hidden overlay stream ownership
These appear related to the same general resume/ownership area, but have different messages and failure paths. I am not claiming this is a duplicate.
This report contains only sanitized technical observations. No raw logs, conversation content, conversation IDs, local usernames, private paths or project details are included.
Activity
a20070322 commentedon Oct 8, 2026
Additional sanitized evidence from macOS on the same desktop version.
Environment
Observations
The user reports that launching the desktop app triggers the problem. Retained logs from three separate process instances contain 390,839 occurrences of
maybe_resume_skipped_inactive_hotkey_window, all referencing the same conversation. This is about 98.6% of the 396,403 timestamped entries in the retained logs for the examined day.These are retained log windows, not complete process lifetimes or measurements of how soon after launch the loop started. Rotation overwrote earlier records. The retained windows total roughly 131 MiB of application logs across these three instances; individual files rotate around 10 MiB. CPU impact during the loop was not measured.
Representative sanitized event (timestamp and conversation ID replaced):
Potentially relevant heartbeat association
An ACTIVE local heartbeat automation, scheduled every 10 minutes, targeted that same conversation. Logs repeatedly reported:
There were 1,281 such warnings in the retained logs for one preceding day, 1,268 for the next, and 62 in the examined day's retained logs. These are warning counts, not proof of that many scheduled executions.
Read-only queries found no matching conversation in either the local threads table or the local thread catalog. This does not establish that the conversation was deleted or that it is absent remotely. The heartbeat association is a diagnostic clue, not a confirmed cause of the resume loop.
Limited mitigation check
We backed up the automation configuration and changed only its status from ACTIVE to PAUSED, then the user relaunched the app. No conversation database or window state was cleared.
During approximately the first two minutes after this launch:
This is only a short observation after both pausing the task and relaunching. It does not prove a lasting fix or isolate which change affected the behavior. Separate startup errors (
thread access deniedandfs/readFile requires an environmentId) were still present.The macOS evidence may help investigate whether restored state or an unavailable heartbeat target can repeatedly trigger this guard. No minimal clean-profile reproduction is available yet. This comment intentionally excludes raw log files, user/account identifiers, conversation IDs, private paths, task/project names, and conversation content.
terrytan95 commentedon Oct 8, 2026
Trigger identified (macOS): heartbeat automation whose
target_thread_idno longer existsReproduced on macOS with a confirmed trigger and workaround.
Environment
Codex (Renderer)pinned at ~130–137% CPU,ChatGPTmain process ~45%, persisting across app restartsEvidence
maybe_resume_skipped_inactive_hotkey_windowat ~4,600 entries/sec, always for the same conversation ID, withrendererWindowVisible=false,rendererWindowFocused=false,documentVisibilityState=visible. About 420k occurrences today; ~10 MB of logs every ~20 s.target_thread_idof an ACTIVE heartbeat automation (kind = "heartbeat", weekly RRULE) in~/.codex/automations/<id>/automation.tomland theautomationstable in~/.codex/sqlite/codex-dev.db.[automations] Heartbeat automation skipped: thread missing ... blockReason=thread_missingand reschedulesnextRunAta few minutes ahead, again and again.sampleof the renderer shows it running JIT'd JS; the main process is mostly idle. So the hot loop is in the renderer: the resume path (#e(...)/dC(...)in the bundle) logs and returns{status: 'not-ready', reason: 'inactive-window'}immediately (no stream role, hidden window can't acquire the thread stream), and the caller retries right away without backoff.Workaround (confirmed)
Quit the app, set the automation's
statustoPAUSEDin bothautomation.tomland theautomationsrow, then relaunch:Codex (Renderer)CPU: ~137% → ~26% and falling once startup finished;ChatGPTmain: ~45% → <13%Suggested fixes
reason: 'inactive-window'. That result can't change until the window becomes visible, so retrying in a tight loop only burns CPU.Raw logs, conversation/thread IDs and automation content are intentionally left out.
Redko-pro commentedon Oct 8, 2026
I encountered the same issue on Codex Desktop 26.1002.52244 (build 13536) running on macOS 26.6.2, MacBook Air M1, 16 GB RAM.
After investigating the high CPU usage, I managed to identify the automation responsible and confirm a workaround.
Symptoms
Codex (Renderer)consistently consumed 120–140% CPU.The logs were flooded with:
We measured 48,956 occurrences in 10 seconds (~4,896 events/sec), all associated with the same conversation and hidden renderer window.
What we discovered
The affected conversation was associated with an ACTIVE recurring automation scheduled to run daily.
I later remembered that I had originally created this automation inside a temporary
/sideconversation. The scheduled task remained active, but its associated conversation could not be found in the inspected local SQLite thread database.Interestingly, I had never received the expected daily task results.
Our investigation of the packaged JavaScript suggested a possible loop:
The temporary
/sideconversation is a suspected trigger, not a confirmed root cause.Confirmed workaround
We paused only the affected recurring automation using the application's normal task-management mechanism.
No application restart, cache cleanup, or other configuration changes were required.
Results:
The event count remained at zero across two consecutive 10-second measurements, and the same main application process continued running normally.
Conclusion
This appears to be a potential unbounded retry loop when a recurring automation references a conversation that cannot be resumed.
The automation itself wasn't performing useful work, yet the application repeatedly attempted to restore its associated conversation, consuming significant CPU resources.
For anyone experiencing this issue: check your active recurring automations, particularly those created from temporary or side conversations. Temporarily pausing the affected automation may immediately resolve the CPU spike.
Ideally, Codex should detect an unavailable conversation and stop retrying indefinitely, or apply a backoff mechanism.
I hope these findings help the team reproduce and fix the issue.
soeprbp commentedon Oct 8, 2026
Windows reproduction of the same inactive-window resume log flood, on the same desktop release.
OpenAI.Codex_26.1002.7124.0_x64.26.1002.52244, build13536, channelprod, statusup_to_date.maybe_resume_skipped_inactive_hotkey_windowmessages (about 1,107/second). A separate 15-second sample contained 13,781.documentVisibilityState=visible,rendererWindowAppearance=primary,rendererWindowFocused=false,rendererWindowVisible=false, androutePath=/index.html.primary.Related macOS report: #52091. This adds Windows evidence to the same event/window-state signature, without asserting that all three platforms have an identical root cause.
Please investigate repeated scheduling or state notifications around the inactive-window resume guard, and backoff/deduplication for this path.
Only sanitized observations are included here: no raw logs, conversation identifiers/content, user paths, account information, private project names, or credentials.
yuzhu-oai commentedon Oct 8, 2026
Fixed has been merged and will be released soon.
phplego commentedon Oct 18, 2026
Thank you for addressing this Linux background-resume problem. I still notice sluggish Desktop interactions on 26.1007.21434: roughly 2-3 seconds to switch chats, frame-rate drops when scrolling long chats, and a sluggish chat list (Intel Core i7, many saved chats).
These are informal user observations. I have not verified an inactive-window log flood or a failing automation on my installation, so this is not evidence that the fixed loop has returned. I am reporting the remaining responsiveness symptoms in #18693 and #11011; please link a more specific current tracker if appropriate. The newly installed 26.1013.40934 is still pending restart and untested.