[Windows] Cross-task tools disappear after offline startup and return after an online restart

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

Windows package OpenAI.Codex_26.908.4834.0_x64; app log release 26.908.40834; bundled CLI 0.153.4. These values were read from installed package metadata and logs, not the About dialog.

What subscription do you have?

Pro (OpenAI provider; no custom Responses provider).

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After a desktop startup during a network outage, existing local tasks lacked the cross-task tool group, including send_message_to_thread, handoff_thread, list_threads, read_thread, and wait_threads. Other desktop tools, including open_in_codex and navigate_to_codex_page, remained available. This blocked an authorized cross-project handoff.

The missing tools were observed in both a Sol task and an Astra task. The app was usable for conversation later, but the task-tool group remained absent until a normal restart. No sending permission rejection was observed: the tools were absent from the callable inventory, rather than advertised calls failing with missing handlers.

Selected log fields, timestamps in UTC:

2026-09-13T16:34:00.828Z
routePattern=/wham/statsig/bootstrap
errorMessage=net::ERR_INTERNET_DISCONNECTED

2026-09-13T16:34:00.829Z
Statsig: error while bootstrapping post-login client
attemptNumber=1
errorMessage=net::ERR_INTERNET_DISCONNECTED

At inspection, that process had zero Concurrent reasoning summaries feature override resolved events. This is supporting evidence of feature-override generation, not a direct measurement of thread_tools.

After restarting the app while online:

2026-09-13T19:12:27.366Z
Concurrent reasoning summaries feature override resolved
featureOverride=true

The new process had no bootstrap/disconnected errors at inspection. The same management conversation regained the missing cross-task tools. Real read_thread calls for both existing project tasks succeeded. No configuration, credential, model-setting or permission changes were made to restore availability.

What steps can reproduce the bug?

This is one observed incident with before/after restart verification, not an independently repeated deterministic reproduction.

Suggested engineering reproduction:

1. Start an otherwise entitled Windows desktop session while offline.
2. Restore connectivity and resume existing local tasks.
3. Inspect whether cross-task tools are exposed without restarting.
4. Compare with the same tasks after an online app restart.

Post-restart tool exposure and actual task reads were verified. Post-restart message sending and recipient acknowledgement were not tested. Private task IDs, project names, account identifiers and full session transcripts are omitted from this public report.

What is the expected behavior?

A temporary startup network failure should recover feature/tool availability when valid configuration can be fetched again, or expose an actionable initialization error and retry path. Missing initialization data should be distinguishable from intentionally disabled features.

A normal restart is an observed workaround, not evidence that the underlying defect is fixed.

Additional information

Suspected mechanism, not fully proven: read-only inspection of the bundled app shows that the post-login bootstrap retries only certain HTTP 401 failures and falls back to an asynchronous initialization path on other errors. Task feature overrides become empty when initial evaluations are absent or fail identity validation. The cross-task tool group requires thread_tools=true (gate 2395575782). SDK live refresh updates a separate live-value store, while task configuration validation reads the initial evaluation data. This may allow an unsuccessful initial state to persist despite subsequent connectivity. Exact renderer evaluation values and server-side flag decisions were not captured.

Please investigate failed-initialization recovery after reconnection, consistency between live refresh and initial-evaluation validation, and regression coverage for offline startup followed by reconnection.

Related reports, with different observed conditions:

• #33947 concerns tools remaining absent after gate re-enable and restart; in this incident the same management conversation recovered after restart.
• #44170 concerns a custom provider after an update; this incident used the OpenAI provider and had a logged startup network failure.
• #44721 concerns Statsig bootstrap connection reset and Browser/plugin availability on macOS; this report adds Windows cross-task tool loss and a verified restart recovery.

Start by tracing Windows offline startup through the post-login bootstrap, feature-override generation, and the thread_tools gate (2395575782), then compare initial-evaluation validation with SDK live refresh after reconnection. Add regression coverage for an offline startup followed by reconnection, verifying that cross-task tools recover or that initialization reports an actionable error without requiring an online restart.