VS Code extension 26.901.22334: unknown special value ["bytes", {...}] after ~2h

What version of the IDE extension are you using?

openai.chatgpt 26.901.22334

What subscription do you have?

prefer not to disclose

Which IDE are you using?

VS Code 1.136.1

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After roughly two hours of normal use, the Codex VS Code extension stops being able to create or submit chats. New chat creation fails with:

• **Error creating chat
• unknown special value: ["bytes", {"0":123,"1":10,"2":32,...}]**

At the same time, requests from the webview to /wham/* endpoints begin failing with status=null. Running Developer: Reload Window temporarily restores the extension for another period of normal use.

The byte payload shown in the error decodes to the beginning of a JSON response body:

{
  "items": [

This suggests that a bytes payload from /wham/tasks/list is reaching the capnweb deserializer in a JSON-object form instead of a supported bytes representation.

• Existing extension session works normally for a while.
• After the failure starts, every new chat or submit attempt fails.
• Reloading the VS Code window temporarily recovers the extension.
• Reinstalling the extension and resetting VS Code state did not prevent recurrence.

What steps can reproduce the bug?

I do not yet have a minimal deterministic reproducer, but the issue has occurred more than once under normal use:

1. Start VS Code with the Codex extension.

2. Use the extension normally for chats/turns/reasoning for around two hours.

3. Observe the first warning similar to:

   Failed to broadcast thread read state ... error={}
   

4. Attempt to create or submit a chat.

5. Observe:

   unknown special value: ["bytes", {"0":123,"1":10,"2":32,...}]
   

6. Observe simultaneous sa_server_request_failed entries with status=null for /wham/* endpoints.

7. Run Developer: Reload Window.

8. Extension works again temporarily.

What is the expected behavior?

After extended normal use, creating or submitting chats should continue to work. If an internal connection drops, the extension should reconnect transparently and preserve the expected bytes encoding without requiring a VS Code window reload.

Additional information

Bundled CLI: 0.153.0

Troubleshooting Already Performed

• Recreated VS Code user-data directory.
• Recreated VS Code extensions directory.
• Confirmed Codex desktop app was not running.
• Confirmed no second VS Code window was open.
• Verified persisted VS Code state database did not appear to be the cause.
• Reinstalled from a clean extension state.
• Issue still recurred.

Suspected Root Cause

This may be a transport/serialization issue after an internal connection drop or reconnect. Specifically, the /wham/tasks/list response body appears to be passed to the capnweb deserializer as a JSON-object representation of bytes rather than as a supported bytes representation.

Start by tracing the /wham/tasks/list response into the capnweb deserializer and reproduce the failure through extended normal use, using the unknown special value and status=null logs as markers. Done means the extension reconnects or preserves valid bytes encoding after the connection issue, so new chats and submissions continue working without a VS Code window reload.