Codex Cannot Serialize Value: What to Check When a New Chat Fails

If a new Codex chat fails with Cannot serialize value: (couldn't stringify value), record the installed version and check for an update first. If it persists, compare a new Local chat with a new Worktree chat in the same project. Do not begin by deleting chat history, replacing API keys, or resetting the repository.

This exact error appeared in October 2026 desktop reports. The reporting thread is now closed, with users reporting recovery on specific macOS and Windows builds. That makes version checking more useful than assuming the old incident is still affecting every installation.

This guide covers a new chat failing at submission, particularly when Worktree is selected. It uses public reports and a conservative diagnostic workflow; Ofox has not reproduced the original failure in a controlled installation. The steps below are checks and conditional alternatives, not a universal repair or a claim that an Ofox API key fixes Codex.

Check the version before applying an old workaround

The following is a summary of issue #55744 in OpenAI’s repository, checked October 28. These are user reports, not a platform-wide support matrix.

The macOS recovery comment and Windows recovery comment are separate observations. An updater saying “up to date” on an older build only describes what that installation can currently obtain; it does not prove that another platform’s reported fix is installed.

Save the unsent prompt somewhere private, finish or pause active work, then use the application’s supported update mechanism. Record the version before and after. Restart when the updater requires it, reopen the same project, and repeat one small submission. Avoid downloading an older app bundle from an unofficial mirror or editing installed application files.

Confirm that this is the same failure

“Serialization” describes converting a value for transport or storage. The wording alone does not tell you which value failed, whether a model request was sent, or whether your repository is damaged.

Record three things before changing settings:

1. Stage: Did the app fail to open, did the first message fail to submit, or did a running task fail later?
2. Mode: Was the new chat Local or Worktree? Was it attached to a Git project?
3. Exact error: Copy the full short message, including the text inside parentheses. Keep any adjacent error separate.

If the actual message is couldn’t load workspace settings, investigate workspace initialization. If the extension says couldn’t load its resources, use the resource-loading guide. If the composer says permission mode is unavailable, follow that submission checklist. Similar timing does not establish a shared cause.

The issue contains client-side serializer investigations, including a hypothesis about rich-text document attributes. Those reports help locate a possible boundary; they do not justify telling every user to strip punctuation, remove Chinese text, or rewrite a repository’s JSON files. A short plain-text prompt is useful as a control, not as a guaranteed fix.

Compare Local and Worktree without risking project changes

Use a disposable diagnostic prompt rather than the real task:

Reply with OK only. Do not read or modify files, run commands,
install dependencies, or start any project task.

Keep the account, project and version constant. First try a new Local chat. Then try a new Worktree chat with the same prompt. Creating a worktree can run a project’s configured setup process: review that configuration first and use a harmless test repository if setup would have side effects. Do not repeat the test across production projects merely to collect more examples.

Stop after obtaining a useful contrast. Repeatedly clicking Send creates noise and can make it harder to identify the first failure. A model reply in Local establishes only that this route worked at that time; it does not test isolation or Worktree setup.

If Local works, choose a temporary path deliberately

Local operates in the selected checkout. A separate worktree provides a different working directory. Switching to Local therefore changes where project operations may happen; it is not an equivalent isolation guarantee.

For a read-only discussion, staying in a successful Local chat may be enough. Before allowing edits, inspect the checkout and coordinate with any other work using it. Preserve uncommitted and untracked files. Do not use git reset --hard, git clean, or cache deletion as generic serialization repairs.

For a task that needs isolation, the issue contains reports of starting in Local and then creating an app-managed worktree. Treat this as a conditional alternative: use it only if that capability is actually available in your installed app, and verify the returned directory before any edits. A suitable instruction is:

Do not edit the current checkout. First identify the intended starting
branch or commit and report its resolved commit. Create a separate
managed worktree using the supported app capability if available.
Report its absolute directory and HEAD. Perform all later project
operations in that directory. If creation or attachment fails, stop
before editing files and report the error.

Replace the starting revision with the one your task actually requires; do not blindly substitute master. A new worktree does not automatically carry over uncommitted changes from the original checkout. If those changes are needed, plan their transfer explicitly after preserving them.

Before continuing, inspect the returned location with read-only Git commands:

git -C /absolute/path/to/worktree rev-parse --show-toplevel
git -C /absolute/path/to/worktree rev-parse HEAD
git -C /absolute/path/to/worktree status --short
git -C /absolute/path/to/worktree worktree list

Use your actual path, quoted if it contains spaces. Confirm the directory is separate, the commit matches the agreed starting revision, and any initial changes are understood. Creating a directory alone is not evidence that the app attached it or that subsequent commands use it. If the app cannot provide the supported capability, keep work read-only or use an already supported development path; do not pretend a plain folder copy is a managed worktree.

Collect diagnostics that support a useful report

Use the app’s supported feedback or diagnostics route. The public reports include TypeError, composer submission failure and mode=worktree; look for the corresponding event around your own test time rather than copying somebody else’s stack trace.

Record only the relevant event and its context. A raw log may contain prompts, local paths, repository names, authentication data or session identifiers. Redact those before sharing. This template is an editorial worksheet, not an observed log:

OS and architecture:
Desktop app version/build:
Test time and timezone:
Exact visible error:
New or existing chat:
Project type: Git / non-Git / none
Local test: succeeds / exact error / not tested
Worktree test: succeeds / exact error / not tested
Update offered and result:
Did a worktree directory get created?
Relevant sanitized diagnostic fields:
What was changed between tests:

Do not label a proposed serializer mechanism as a confirmed root cause on your machine. For maintainers, the useful distinction is whether the failure occurs before a worktree exists, during setup, or after a task starts. Provide that distinction and a minimal reproduction without uploading proprietary source code.

Decide whether recovery is complete

Recovery means the operation you needed works again, not merely that a banner disappears. For a direct Worktree failure, verify a fresh Worktree chat accepts the small prompt, the app shows the intended checkout, and a second new chat also starts. Then resume a small real task in the verified directory and inspect its changes.

If only Local works, record temporary alternative available; direct Worktree creation still failing. If an update is unavailable, retain the version and diagnostic evidence for support. If the error has changed, investigate the new signature through the Codex error index instead of applying every remedy in the old thread.

Ofox publishes this troubleshooting guide for developers. Changing model providers, purchasing API credits or increasing model limits does not establish a repair for a desktop serializer failure.