[Windows Desktop] Existing Local Work chats have Send disabled while new Work chats can send

Summary

Existing Local Work chats in the ChatGPT Windows desktop app can no longer submit messages.

Text can be entered into the composer, but the Send button remains disabled.

A newly created Local Work chat can send messages normally.

This appears to affect restoration/initialization of existing Local Work chats rather than Local Work globally.

Environment

• ChatGPT Windows desktop app: 26.915.4065.0
• Windows 10 Pro 22H2
• OS Build: 19045.4651
• Agent environment: Windows native
• Integrated terminal shell: PowerShell
• WSL: Not currently available (wsl command is not recognized)

Reproduction / A-B test

Existing Local Work chats

1. Open an existing Local Work chat.
2. Enter text in the composer.
3. Send remains disabled.
4. Three-dot menu continuously shows "Loading scheduled tasks..."
5. Ctrl + backtick does not open the integrated terminal.
6. Opening/interacting with the affected Work chat does not create or modify a transcript under .codex\sessions.

Result: Cannot submit any message.

Brand-new Local Work chat

1. Create a new Local Work chat.
2. Enter and send a message.

Result: Sending works normally.

However:

• "Loading scheduled tasks..." still loops indefinitely.
• Ctrl + backtick still does not open the integrated terminal.

Because scheduled tasks also remain stuck in the new Work chat while Send works, the scheduled-task loading loop does not appear to be sufficient by itself to cause the disabled Send button.

Diagnostics already performed

• Fully quit and restarted the desktop app

• Confirmed app is up to date

• Signed out and back in

• Windows app Repair

• Windows app Reset

• Checked for approval prompts: none

• Renamed/recreated .codex\thread-writer-locks: no change

• Tested Windows sandbox with:

  • sandbox = "elevated"
  • sandbox = "unelevated"

  Same behavior in both modes.

• Codex itself works normally in the same desktop app.

• Regular ChatGPT web works normally.

• Windows PowerShell can execute commands such as git status and pwd normally.

Logs / session behavior

When reproducing the issue in an affected existing Work chat:

• No new session transcript is created or modified under:
  %USERPROFILE%\.codex\sessions
• No current sandbox log is generated/updated under:
  %USERPROFILE%\.codex\.sandbox

The latest available sandbox log predates the current failure.

Diagnostic ID

Feedback was submitted through the working Codex interface because the affected Work composer cannot submit / feedback.

Diagnostic/session ID:

no-active-thread-01a0bcc0-39ac-70f3-a356-9881514543b7

Expected behavior

Existing Local Work chats should initialize normally and allow messages to be submitted, just like newly created Local Work chats.

Ideally, there should also be a supported recovery path for an existing Local Work chat if its thread/session state cannot be restored.

Additional note

I have preserved the existing affected Work chats and .codex data and have not deleted the session history.

Start by reproducing the existing-versus-new Local Work chat A/B test in the Windows desktop app and inspect restoration and session initialization, including the .codex\sessions behavior. Done means existing chats initialize, enable Send, and allow normal message submission without regressing newly created chats.