[Windows] App stuck on logo splash at startup (renderer misses the initial local app-server "connected" state), and Windows sandbox setup always fails with "only managed permission profiles can be enforced by the Windows sandbox" #49718

Activity

1. arthurmarabin

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Sep 30, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   sandboxIssues related to permissions or sandboxingIssues related to permissions or sandboxing

   on Sep 30, 2026
3. github-actions commented on Sep 30, 2026

   

   github-actionsbot

   on Sep 30, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Windows][26.924.2738.0] Startup spinner forever in most launches: renderer root never mounts; restarting child codex.exe fixes it (analysis + workaround) #48896
   • Windows desktop 26.928.2636.0 hangs at gray logo; renderer reload restores original profile and history #49631
   • [Windows Sandbox] Setup fails when sandbox_mode is danger-full-access and cannot self-heal DACL on .sandbox-bin #49299
   • # Windows desktop startup stays at splash until local app-server is terminated #49506
   • Release 26.928.2636.0 hangs indefinitely on splash screen; Beta works on same PC #49687

   Powered by Codex Action
4. arthurmarabin commented on Sep 30, 2026

   

   arthurmarabin

   on Sep 30, 2026

   Author

   More actions

   Update: workarounds that work for both problems

   Sandbox setup ("only managed permission profiles can be enforced by the Windows sandbox")

   The setup succeeds if it runs with a sandboxed permission mode, even though the saved config still says danger-full-access. After setup, Full access works normally again, and readiness stays ready with the unchanged config.

   What I did:

   1. With the app open, I ran the bundled app-server with a one-off override. config.toml was not edited:

      codex.exe -c sandbox_mode="workspace-write" app-server
      -> windowsSandbox/setupStart {"mode":"elevated","cwd":"<a project dir>"}
      <- {"result":{"started":true}}
      

      This time the UAC prompt appeared. The helper created CodexSandboxOffline / CodexSandboxOnline and wrote ~/.codex/.sandbox/setup_marker.json (version 5).
   2. The elevated codex-windows-sandbox-setup.exe then spent about 20 minutes in the "read ACL run" phase. It grants read ACEs to the sandbox users on everything under the user profile. My Documents has about 930k files, and the log sat on granting read ACE to C:\Users\<user>\Documents for most of that time. It finished with read ACL run completed and no setup_error.json.
   3. Then windowsSandbox/readiness returned {"status":"ready"} with the normal config (sandbox_mode = "danger-full-access"). After an app restart the "Windows setup was not completed" banner was gone, and messages send in Full access.

   Changing the permission picker in the composer is not enough. It only affects the current thread, and "Redo setup" keeps reading the global sandbox_mode, so it keeps failing instantly. The setup also gives no progress feedback during the long ACL phase. It just looks hung.

   Startup splash hang

   Confirming the workaround from #48896: while the window is stuck on the logo, kill only the child codex.exe ... app-server process and leave ChatGPT.exe running. The app respawns the app-server and the UI mounts within a few seconds. This worked on both of my restarts today, and both launches had hung. This is consistent with the missed hostId=local connection-state race described above.

   Side effect worth knowing if you debug this by launching the exe directly

   If you launch ChatGPT.exe directly (outside package activation), it creates the real %APPDATA%\Codex and %LOCALAPPDATA%\Codex folders. After that, the packaged app also starts reading and writing the existing real %APPDATA%\Codex\web\Codex files, because MSIX uses real AppData files when they already exist. The result is a split profile. In my case the UI language also flipped from pt-BR to English, probably because of this. Removing those two folders with the app closed restored the normal LocalCache-only profile.
5. Nikechukwugrd commented on Sep 30, 2026

   

   Nikechukwugrd

   on Sep 30, 2026 – with ChatGPT Codex Connector

   More actions

   I am experiencing the same Windows startup failure today (September 30, 2026) on a ChatGPT Plus account.

   The app opens to the centered OpenAI/Codex logo on a dark background and remains there indefinitely. The main UI never renders.

   Troubleshooting already attempted:

   • terminated all ChatGPT/Codex processes
   • restarted Windows
   • Windows Repair/Reset
   • uninstall/reinstall
   • clean reinstall
   • local cache/state cleanup

   A clean reinstall temporarily made the app work. I then spent about 30 minutes recovering/re-locating previous project files and getting my chats/project state back. After that, a later launch returned to the exact same infinite loading screen.

   This is especially disruptive because deleting/resetting local Codex state can temporarily make existing project/chat state disappear. Users should not have to purge ~/.codex or other local project/session state just to launch the app.

   My visible failure is the same as described here:
   Windows app opens → centered logo/spinner → indefinite hang → no sidebar/composer/UI.

   Please prioritize a fix that preserves existing conversations, project/workspace registrations, and local Codex state. I can provide a screenshot of the frozen splash screen and additional diagnostics/logs if useful.
6. Akhull commented on Oct 1, 2026

   

   Akhull

   on Oct 1, 2026 – with ChatGPT Codex Connector

   More actions

   Additional diagnostic evidence for the startup/logo hang on Windows, collected on 2026-10-01. This also records a separate user-reported follow-up-send problem. The sandbox setup failure in the original issue was not established on this machine.

   Environment and user impact

   • Windows 11 Pro, x64, OS/build 10.0.26200.
   • Store package: OpenAI.Codex 26.928.3736.0.
   • Internal app release: 26.928.31416, build 12553, Owl runtime.
   • Local app-server version: 0.159.2; another backend snapshot reported 0.1.0.
   • The built-in update check reported up_to_date during today's investigation.
   • Repeated normal launches have left the primary window at the logo on a dark background, with no usable sidebar/composer. The avatar surface has sometimes remained usable.
   • The user also reports being able to send the first message in a chat but subsequent sends hanging, requiring another chat. The current follow-up-send failure has not yet been captured with a live renderer-state inspection, so its exact cause remains unconfirmed.

   Controlled startup reproduction

   The same installed official program was launched in isolated CODEX_HOME and Chromium profiles using Invoke-CommandInDesktopPackage. Package identity was verified in both comparison instances. Existing authentication/configuration was copied locally for the test; original chat databases and automations were not copied. Comparing saved UI atoms against empty UI atoms reproduced the logo hang in both variants.

   This reproduces the startup failure with fresh Chromium profiles and without copied chat databases. It is not a full original-profile acceptance test.

   Runtime observations

   1. startupReady was fulfilled, but the primary app/onboarding gate still showed gatewayReadiness=loading.
   2. Authentication was already settled: authIsLoading=false, authMethod=chatgpt, hasChatGptToken=true. Feature access was allowed and onboarding had fetched.
   3. The renderer's local appServerVersion value was null, although the main process already knew 0.159.2. This missing value kept the readiness gate loading.
   4. Six startup read queries stayed pending/fetching with dataUpdatedAt=0:
      • locale-info
      • inbox-items
      • list-automations
      • codex-command-keymap-state
      • codex-home
      • get-global-state(selected-remote-host-id)
   5. Calling fresh original QueryFns for codex-home and selected-host state returned in approximately 0.9/0.1 ms in a blocked test instance, while the original queries remained pending.
   6. Cancelling/refetching all six reads restored success/idle, but alone did not release the logo gate. The missing version snapshot still mattered.
   7. A primary-renderer reload opened both comparison instances. Afterwards appServerVersion=0.159.2 and gatewayReadiness=ready.

   Early trace and narrower recovery experiment

   An early trace, without debugger pauses, recorded a local version message at approximately 171.7 ms, the shared message bus at 199 ms, and the corresponding version handler at 2939.9 ms. Initial fetch and ready(initializationOnly=true) requests later remained unanswered; new reads after approximately 6.6 s succeeded.

   Native sendMessageFromView promises resolved even for requests whose answers were not observed. Successful native submission is therefore not proof that the renderer received a usable response.

   A later ready(initializationOnly=true) handshake returned genuine version snapshots and released the logo gate without reloading the renderer or restarting the main process/backend. The six old queries then still required cancellation/refetch using their original QueryFns.

   A diagnostic prototype combined:

   • a check after about 10 seconds;
   • a bounded retry of the existing initialization-only handshake;
   • bounded cancellation/refetch of those known stale startup reads;
   • at most three attempts with time limits, without resubmitting chats or other writes.

   It opened 3/3 isolated blocked cold starts, each using one recovery attempt, and reduced stale startup reads from six to zero. One run used empty saved UI atoms. No invented version values were inserted. This prototype depends on private React structures and is not a production-ready extension or installed permanent fix.

   What is still unproven

   We have not identified whether the initial requests are skipped in main-process handling or their responses are lost on the return path. The early version/handler ordering is evidence of a vulnerable startup sequence, not a complete proof of the exact lost message. No chunked-message traffic was observed in the failing trace; a chunk/ACK explanation is unproven. Disabling automatic avatar opening did not eliminate the hang. Debugger timing could change the outcome.

   Repeated actual sends in the original primary window and long-term cold-start reliability were not verified in these experiments. An older build previously had a confirmed loading-local-config submit block with pending codex-home queries, recovered by retrying those reads, but that historical cause must not be assumed for the latest send symptom.

   Requested engineering fix

   Please investigate initial snapshot delivery and startup request completion, retain/replay early version/connection state, and use bounded initialization-handshake and idempotent-read retries with an explicit recoverable error instead of an infinite logo screen. Regression coverage should include cold starts, delayed renderer subscribers, lost startup responses, multiple windows and two successive messages in an existing chat.

   Original application/package files, chat data and configuration were not reset during these experiments. No auth files, tokens, account identifiers, chat contents, personal filesystem paths or unreviewed raw traces are attached to this public report.
7. XAN9xXx commented on Oct 1, 2026

   

   XAN9xXx

   on Oct 1, 2026 – with ChatGPT Codex Connector

   More actions

   I can reproduce the startup/hydration issue on Windows 10 with Microsoft Store package OpenAI.Codex 26.928.3736.0 and local app-server 0.159.2.

   I am only reporting the startup/UI hydration problem here; I have not reproduced the sandbox issue from the original report.

   I observed two useful variants.

   1. The UI can recover without restarting the app-server

   In one launch, the local app-server initialized successfully and remained the same process throughout the hang and recovery.

   13:47:14.753Z  initialize_handshake_result ... outcome=success
   13:47:14.754Z  app_server_connection.state_changed ... hostId=local ... next=connected
   

   config/read also succeeded repeatedly while the splash was still visible.

   Much later:

   13:48:56.195Z  remote_connections.manager_state_set
                    hostId=local
                    previousState=disconnected
                    nextState=connected
   
   13:48:57.373Z  [startup][renderer] app routes mounted after 102783ms
   13:48:57.375Z  Handled 'ready' message
   

   The app-server PID did not change. This seems consistent with the renderer missing or not applying the initial local connection state, then recovering when a later host_connection_state_changed event arrives.

   2. Page.reload was not an immediate/reliable workaround in another reproduction

   I launched the packaged app with --remote-debugging-port=9333 through package activation and reproduced the stuck splash again.

   The local backend was already connected and the main window was ready:

   14:44:50.252Z  app_server_connection.state_changed ... hostId=local ... next=connected
   14:44:50.578Z  window ready-to-show
   

   Auth/config reads also succeeded, but the UI remained stuck.

   I sent CDP Page.reload to app://-/index.html at 15:01:33Z. The app-server PID remained unchanged.

   The reload did not immediately recover the UI. Instead, the renderer later logged:

   15:03:14.977Z  remote_connections.manager_state_set
                    hostId=local
                    previousState=disconnected
                    nextState=connected
   
   15:03:16.489Z  [startup][renderer] app routes mounted after 102862ms
   15:03:16.491Z  Handled 'ready' message
   

   102862ms aligns closely with the time since the renderer reload. So on this machine, reloading the primary renderer appears able to hit the same startup race again rather than reliably fixing it.

   I later replayed:

   window.electronBridge.sendMessageFromView({
     type: "ready",
     initializationOnly: true
   })

   but that happened at 15:04:52Z, after routes had already mounted, so it was not responsible for this recovery.

   After the shell became visible, the app was also not fully healthy: config/read continued to succeed, but I observed separate startup failures/timeouts including Statsig bootstrap, model refresh, and app/list. I am not claiming those are the cause of the splash hang, only that a visible shell did not necessarily mean startup/hydration had fully completed.

   I can provide a sanitized log excerpt if useful.
8. XAN9xXx commented on Oct 1, 2026

   

   XAN9xXx

   on Oct 1, 2026 – with ChatGPT Codex Connector

   More actions

   Additional observation after checking Windows AppX deployment history:

   The startup failure became effectively deterministic for me after updating to OpenAI.Codex 26.928.3736.0. Before this update I did not observe this high failure rate.

   I checked Microsoft-Windows-AppXDeploymentServer/Operational and found the following timeline:

   • 14:19:29 — OpenAI.Codex_26.928.3736.0_x64__2p2nqsd0c76g0 Stage started.
   • 14:19:44 — Stage completed successfully.
   • 21:32:14 — Windows attempted to update 26.928.2636.0 to 26.928.3736.0, but the registration failed because the application was still running:

   0x800700E9: Cannot install because the following app needs to be closed:
   OpenAI.Codex_2p2nqsd0c76g0!App
   

   • 21:40:10 — After another maintenance/register cycle, the 26.928.3736.0 package registration completed successfully.

   I cannot conclude that the AppX update lifecycle caused the startup race, because similar startup issues have been reported on older builds as well. However, the timing is notable: the failure rate changed from occasional to nearly every cold launch after this update.

   This may be useful as an additional variable when investigating whether package update/relaunch state, persisted desktop state, or initialization timing changes affect the renderer/app-server startup handoff.
9. SteveStich commented on Oct 1, 2026

   

   SteveStich

   on Oct 1, 2026 – with ChatGPT Codex Connector

   More actions

   I reproduced the startup race on a separate Windows 10 machine and found a clean workaround that preserves the ChatGPT side of the unified desktop app.

   Environment:

   • Windows 10 Pro 22H2 / 10.0.19045 x64
   • OpenAI.Codex MSIX 26.928.3736.0
   • desktop bundled app-server reports 0.159.2
   • standalone CLI updated to 0.159.3 (updating the CLI did not fix the desktop hang)

   Startup evidence matches this issue closely:

   • local app-server initializes and reaches post_initialize_connection_state ... hostId=local ... next=connected within ~0.4s
   • renderer never receives/logs remote_connections.manager_state_set hostId=local
   • durable host later logs normal manager_state_set ... connected
   • app remains indefinitely on the centered OpenAI logo
   • the 300000 ms in_app_updates_policy_timeout fires after 5 minutes but does not recover the UI

   Important secondary finding: killing the child codex.exe app-server is NOT a clean workaround on this build. It wakes the shell, but afterward the ChatGPT cloud side becomes partially broken:

   • existing local/Codex threads can work
   • ChatGPT "New chat" does nothing
   • recent web chats do not appear
   • desktop search cannot find newly created web chats
   • logs show Desktop network policy does not allow this destination, then Authenticated workspace changed for requests including /wham/tasks/list, /wham/onboarding/context, and /settings/user

   By contrast, reloading only the main Electron renderer via Chrome DevTools Protocol fixes the splash hang AND preserves normal ChatGPT behavior (Recents sync, search works, New chat works).

   For the Store/MSIX build, launching ChatGPT.exe directly with Start-Process returns Access denied, so I used package-context launch:

   $pkg = Get-AppxPackage OpenAI.Codex
   $exe = Join-Path $pkg.InstallLocation "app\ChatGPT.exe"
   
   Invoke-CommandInDesktopPackage `
     -PackageFamilyName $pkg.PackageFamilyName `
     -AppId "App" `
     -Command $exe `
     -Args "--remote-debugging-address=127.0.0.1 --remote-debugging-port=9333"

   Then, after allowing startup to settle (~20 seconds), re-query the CDP targets and send Page.reload specifically to app://-/index.html:

   $targets = Invoke-RestMethod "http://127.0.0.1:9333/json/list"
   $target = $targets |
     Where-Object { $_.url -eq 'app://-/index.html' } |
     Select-Object -First 1
   
   $ws = [System.Net.WebSockets.ClientWebSocket]::new()
   $ws.ConnectAsync(
     [Uri]$target.webSocketDebuggerUrl,
     [Threading.CancellationToken]::None
   ).GetAwaiter().GetResult()
   
   $msg = '{"id":1,"method":"Page.reload","params":{"ignoreCache":true}}'
   $bytes = [Text.Encoding]::UTF8.GetBytes($msg)
   $segment = [System.ArraySegment[byte]]::new($bytes)
   
   $ws.SendAsync(
     $segment,
     [System.Net.WebSockets.WebSocketMessageType]::Text,
     $true,
     [Threading.CancellationToken]::None
   ).GetAwaiter().GetResult()
   
   $ws.Dispose()

   Timing mattered in automation: sending the reload only ~1.5s after discovering the renderer did not reliably work. Waiting ~20s, then re-querying /json/list to get the current renderer/WebSocket URL immediately before Page.reload, worked reliably.

   This looks like strong confirmation that the primary failure is renderer bootstrap/state replay rather than app-server health. A renderer reload fixes the app without disturbing the authenticated ChatGPT workspace, whereas app-server restart can create a second workspace-routing failure.
10. ver102-cmd commented on Oct 2, 2026

    

    ver102-cmd

    on Oct 2, 2026 – with ChatGPT Codex Connector

    More actions

    Additional report for the Windows startup/logo hang, based on troubleshooting performed on 2026-10-02 (Asia/Seoul). This concerns startup recovery; the sandbox setup error in the original issue was not established in these tests.

    Environment and impact

    • Windows desktop app, reported release family: 26.928.
    • Exact package/app-server version and Windows build were not re-verified for this report; please do not assume they match the original issue.
    • The desktop window remains on the startup logo/blank screen instead of loading the main interface.
    • Moving authentication state aside and signing in again provided a temporary workaround, but required repeated sign-in.

    Sandbox readiness test

    While the desktop UI remained stuck, a separate app-server process was started and queried directly with windowsSandbox/readiness. It returned status: ready.

    This weakens the hypothesis that the UI is waiting for incomplete sandbox setup. Because this query used a separate app-server, it does not prove that the stuck desktop process had received the same readiness response or shared every launch parameter.

    Startup-log comparison recorded in earlier diagnostic notes

    The earlier troubleshooting summary records a comparison of 13 launches:

    • 5 successful launches: remote_connections.manager_state_set for hostId=local was present.
    • 8 stuck launches: that renderer-side local-state marker was absent.
    • The notes describe backend initialization/connection completing at approximately 0.3 seconds, with renderer startup several seconds later.
    • Successful launches were associated with later app-server warnings and subsequent renderer-side local-state delivery.

    These are previously recorded diagnostic observations, not newly re-audited raw-log excerpts. The original logs are not attached to this comment. The warning/state correlation alone does not establish causation.

    Recovery test and user confirmation

    In a launch recorded as still stuck after approximately 15 seconds, only the desktop child codex.exe app-server was terminated; the desktop UI process was left running. The desktop app respawned its backend.

    The diagnostic notes then recorded local-state entries, renderer route mounts, and model-list requests. The user subsequently confirmed that the application worked and that relaunching also worked. No authentication-file move or fresh login was needed for this recovery.

    This verifies a useful recovery on this machine, but does not establish long-term cold-start reliability. ChatGPT cloud sync, search, and all other surfaces were not systematically tested after the backend restart.

    Other isolation attempts recorded

    • Emptying configuration did not prevent the startup hang.
    • Moving database/app state aside did not provide a lasting fix.
    • Authentication reset/sign-in could temporarily open the app.

    These tests do not prove file corruption. Fresh-profile completeness and all launch-path differences were not independently verified.

    Interpretation and requested investigation

    The observations are consistent with an initialization/state-delivery failure between the backend/main process and renderer, as discussed here and in #49557. The exact initiating race or lost message remains a hypothesis.

    Please investigate:

    1. Retaining and delivering the latest local connection/version snapshot when the renderer subscribes, including both fast-backend/slow-renderer and slow-backend/fast-renderer startup.
    2. Completion of initial renderer requests, with bounded retries for the initialization handshake and idempotent startup reads.
    3. An actionable startup timeout/retry UI instead of an indefinite logo screen.
    4. Regression coverage for repeated signed-in cold launches, relaunches after updates, multiple windows, and ChatGPT cloud functionality after recovery.

    No raw logs, credentials, account identifiers, personal paths, or conversation contents are attached.
11. TucikCoder commented on Oct 2, 2026

    

    TucikCoder

    on Oct 2, 2026

    More actions

    The startup splash hang still occurs with Codex for Windows 26.928.40906 (build 12694), on every launch on two different AMD PCs. Reinstalling and regenerating .codex/config.toml did not help.

    An additional workaround consistently restores the UI immediately: terminate only the ChatGPT.exe renderer processes:

    Get-CimInstance Win32_Process | Where-Object { $_.Name -eq 'ChatGPT.exe' -and $_.CommandLine -match '\-\-type=renderer' } | ForEach-Object { Stop-Process -Id $_.ProcessId -Force }

    The main ChatGPT process and Codex app-server remain running and functional. The hang returns on the next launch. This concerns the startup issue; it does not confirm the proposed root cause or the separate sandbox issue.

    I have also experienced automatic updates not working, but that has not been independently verified or linked to this hang. The current update check reports the installed version as up to date.
12. XAN9xXx commented on Oct 2, 2026

    

    XAN9xXx

    on Oct 2, 2026 – with ChatGPT Codex Connector

    More actions

    Additional observation from a 26.928.3736.0 Windows 10 startup today: the app reached the visible shell after reproducing the same delayed local-host state transition, but the resulting session was not fully initialized.

    The startup timing again matched the race described here:

    06:06:59.867Z  main/AppServerConnection:
                     hostId=local ... next=connected
    
    06:08:41.383Z  renderer:
                     remote_connections.manager_state_set
                     hostId=local
                     previousState=disconnected
                     nextState=connected
    

    So the main process knew the local app-server was connected about 101.5 seconds before the renderer applied that state.

    This time, however, the UI that eventually appeared was visibly incomplete/default-looking (English UI and missing/newer feature state). The running package was still OpenAI.Codex 26.928.3736.0, and the log identified the frontend release as 26.928.31416, so this was not an actual binary rollback.

    In the same startup, the post-login Statsig bootstrap failed:

    Statsig: error while bootstrapping post-login client
    attemptNumber=6
    errorMessage="Timed out while fetching post-login Statsig bootstrap"
    

    Shortly afterwards:

    browser_use_availability_resolved
    available=false
    platform=Windows
    reason=statsig-disabled
    release=26.928.31416
    

    Bundled-plugin reconciliation then wrote a reduced runtime marketplace:

    pluginCount=3
    pluginNames=["codex-app-tools","latex","visualize"]
    

    and removed:

    browser@openai-bundled
    unified-computer-use@openai-bundled
    

    It also attempted to remove chrome@openai-bundled, but that failed with:

    failed to remove existing plugin cache entry:
    Access is denied. (os error 5)
    

    causing bundled_plugins_reconcile_failed.

    app/list subsequently failed twice after ~60 seconds with:

    failed to list apps: Failed to parse JSON response
    

    There are existing reports for parts of this second symptom:

    • Windows: Statsig bootstrap fails on user.custom.workspace_type, disabling i18n and Browser Use #26780 — Windows Statsig bootstrap failure with English UI / statsig-disabled
    • Windows Codex 26.527 package includes Browser/Computer Use but runtime gate exposes only latex #25253 — Windows statsig-disabled producing a reduced bundled marketplace
    • [macOS] Statsig bootstrap connection reset followed by Browser disabled and automatic bundled-plugin removal on unchanged build #44721 — macOS report with the particularly similar sequence of Statsig failure → statsig-disabled → ["codex-app-tools","latex","visualize"] → bundled Browser/Chrome/Computer Use removal

    I am not claiming that the startup local-state race causes the Statsig/plugin failure. They may be separate failures occurring during the same unhealthy startup. The useful observation here is that recovering past the splash/loading gate does not necessarily leave the Desktop fully hydrated or usable.

    In this instance, config/read, authentication, and later model/list calls were succeeding, while Statsig/plugin/apps initialization remained degraded.
13. tomhda commented on Oct 2, 2026

    

    tomhda

    on Oct 2, 2026

    More actions

    For the logo splash: sending {type: 'ready', initializationOnly: true} through electronBridge.sendMessageFromView from the stuck window makes the main process re-send the initialization snapshot, and the app opens immediately without a reload (seen on 26.928.31416, 26.928.40906 and 26.930.21537). The one-time codex-app-server-initialized message is sent before the renderer listens and is not kept for later.

    Messages that arrive before the renderer is ready can also stall the whole host→window channel when they are chunked: #50203