What version of the Codex App are you using (From “About Codex” dialog)?

26.908.31457

What subscription do you have?

20x pro

What platform is your computer?

mac os

What issue are you seeing?

What steps can reproduce the bug?

Codex 26.908.31457: circular module dependency causes startup and pet-window errors

Summary

A circular dependency in the shipped frontend bundle causes an initializer to be called before it has been assigned, depending on module evaluation order. The error was reproduced using code extracted from the installed application in a separate Chromium instance. Breaking the dependency cycle allowed all five tested entry and prefetch scenarios to complete successfully.

The visible symptom is the “ChatGPT hit a snag” recovery screen during startup. The user also reports the same screen in the pet window after selecting “Show pet.” The failure can occur outside Electron, so the application’s frontend module dependency graph is sufficient to explain this error.

Environment and investigation scope

• Application version: 26.908.31457, build 8690.
• The two application bundle copies, in Applications and Downloads, have identical app.asar files.
• app.asar SHA-256: a10aceafa8d904999e0226344896bc7346e16ef0333d0694bbf1d950ad4105a8.
• Reproduction engine: isolated Chromium 145.0.7632.6.
• Minimal ECMAScript module (ESM) experiments: Node.js 24.20.0.
• The installed application bundle was inspected without modification. The running application was neither restarted nor modified during this investigation. The experimental patch was applied only by substituting resource responses in the isolated browser.
• Each browser scenario used a fresh temporary context. Page requests to external hosts were blocked, and application resources were served from locally extracted files.

Exact failure location

TypeError: r is not a function
    at authed-route-70c1c8333037.js:1:1573

This matches the message recorded in the desktop logs for Initial route prefetch failed and the AppRoutes error boundary. The desktop logs contained only a simplified Error; the isolated reproduction captured the original TypeError and its file location.

Dependency cycle

app-primary-1e3e98d65d25.js
  └─ statically imports n / t from authed-route to obtain a smartphone icon
       └─ authed-route imports kc from app-primary and calls it as r() at module scope
            └─ kc refers to var uzn in app-primary, which has not yet been assigned

The relevant relationships in the bundled code are shown below. These are shortened excerpts from separate modules, not a standalone script:

// app-primary: imports a shared icon from the route module.
import { n as mZe, t as hZe } from './authed-route-70c1c8333037.js';

// authed-route: imports an initializer from app-primary and calls it at module scope.
import { Dc as t, Oc as n, kc as r } from './app-primary-1e3e98d65d25.js';
// ...icon definition...
r();

// app-primary: assigns the bundler-generated initializer later during evaluation.
var uzn = t(() => { /* ... */ });
export { uzn as kc };

When evaluation begins through app-primary, its dependency authed-route executes before the assignment to uzn has run. The var binding is therefore still undefined, and the top-level r() call throws a TypeError.

Loading authed-route first and then loading HomeComposerRoute succeeds in the isolated reproduction.

Bundle coordinates for source mapping or further investigation (line:column):

• app-primary-1e3e98d65d25.js:2:44341: imports the icon from the route module.
• app-primary-1e3e98d65d25.js:1114:611796: assigns the uzn initializer.
• authed-route-70c1c8333037.js:1:1573: the call that throws.

Why startup can trigger the failure intermittently

The startup prefetch function, o8a, prefetches AuthedRoute and HomeComposerRoute concurrently. With descriptive names substituted for the minified variables, its behavior is:

await Promise.all([
  AuthedRoute.prefetch(),
  HomeComposerRoute.prefetch(),
]);

HomeComposerRoute imports app-primary directly.

The shipped preload helper records a shared CSS URL before its stylesheet finishes loading. The first prefetch waits for that stylesheet’s load event. A subsequent prefetch sees that the URL has already been recorded and continues without waiting for the same stylesheet. This can allow the later HomeComposerRoute request to enter module evaluation first.

An experiment using the application’s original preload helper and a minimal version of the dependency cycle produced the following results:

This verifies a concrete mechanism that can change the evaluation order. Resource timing was not captured for every failure in the running desktop application, so this does not establish that every observed failure was triggered by the same CSS timing sequence.

Why “Show pet” can trigger the same error

Importing the pet module itself succeeds. However, its shared page container also mounts WorkspaceSettingsWebviewHost:

Shared container used by the pet window
  → WorkspaceSettingsWebviewHost
  → webview-page-f5e8f4c88b2c.js
  → app-primary
  → authed-route’s top-level r() call

The lazy host is mounted unconditionally by that shared container in app-initial. The webview-page module statically imports app-primary.

In the isolated browser, importing the pet module and then the host module reproduced the same error at the same location. This supports the dependency chain identified through static inspection; it is not a full interaction test of the production pet window.

Original bundle versus isolated experimental fix

The experimental fix made only two changes:

1. Extract the smartphone icon into a separate module.
2. Change the icon import in app-primary to reference that new module.

The route logic was left unchanged.

To invoke the otherwise unexported startup prefetch function from the test page, test exports were appended to the response for the extracted module. The function bodies were not modified.

Recorded browser results are included in evidence.json. The patch description and hashes are in fix-manifest.json.

Minimal reproduction

From the accompanying minimal-repro directory, run:

node run.js authed-route
node run.js home-composer-route
node concurrent.js cold
node concurrent.js warm

Expected results, in order:

1. Success.
2. TypeError: r is not a function.
3. Both concurrent requests fail with the same error.
4. Both concurrent requests succeed.

This reduced example preserves the dependency cycle and the var initialization order. It is separate from the full-bundle Chromium experiments described above. The concurrency example uses the preload helper extracted from the installed application and a small simulated DOM for stylesheet loading.

Suggested fix and validation limits

Remove the reverse dependency from the primary application module to the route module. Shared icons should be defined in an independent module rather than exported from a route module that depends on the primary application module.

Regression coverage should exercise the bundled output through the direct primary entry, concurrent startup prefetch, and the shared host used by the pet window.

No verified config.toml workaround was found. Clearing caches does not remove the dependency cycle.

The isolated patch eliminated the TypeError in the tested import and prefetch scenarios. It has not been installed into the production application, and complete desktop functionality has not been regression-tested. These results should not be interpreted as a claim that the user’s running client has already been fixed.

What is the expected behavior?

No response

Additional information

No response