›_ Codex Issues
Codex Issues / #25865

Codex App freezes when pasting JSON stack traces with escaped backslashes into composer

Open 💬 9 comments Opened Jun 2, 2026 by iwbtamkn47
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.527.60818 (3437)

What subscription do you have?

Enterprise

What platform is your computer?

Darwin 24.6.0 arm64 arm

What issue are you seeing?

Codex Desktop freezes when I paste a medium-sized JSON stack trace into the composer.

The renderer process stays near 100% CPU and the UI becomes unresponsive. This happens in a new chat as the first pasted input, so it does not appear to be caused by thread history size.

The trigger is a JSON array such as stackTrace: [ containing many escaped stack-frame strings with sequences like \" and \n. This is common when copying AWS Lambda / Python stack traces as JSON:

{
  "stackTrace": [
    "  File \"/var/task/src/application/services.py\", line 688, in fetch_events\n    events = future.result()\n"
  ]
}

Important observations:

  • Pasting random ASCII text of the same length does not freeze.
  • Pasting multiline random ASCII text of the same length does not freeze.
  • Pasting JSON-like text without escaped backslashes does not freeze.
  • Pasting File \"...\", line ... text outside a JSON/bracketed structure does not freeze.
  • Pasting text at or above 5000 characters does not freeze because Codex converts it into Pasted text.txt.
  • Pasting under 5000 characters freezes because it is inspected and inserted directly into the composer.

This looks like catastrophic backtracking in the paste-time Markdown link / rich prompt detection regex, not a backend/Lambda issue or spellcheck issue.

What steps can reproduce the bug?

  1. Open Codex Desktop.
  2. Open a new chat.
  3. Paste a generated text under 5000 characters that contains:
  • an opening [
  • many backslash escape sequences such as \"
  • no valid Markdown link terminator ](...)
  1. Observe that Codex Desktop becomes unresponsive and a renderer process pegs CPU near 100%.

Minimal generator:

const target = 4991;
let text = '{\n  "stackTrace": [\n';
let i = 0;

while (text.length < target) {
  text += `    "alpha beta gamma \\"quoted\\" delta epsilon ${i}",\n`;
  i += 1;
}

text = text.slice(0, target);
console.log(text);

I also reproduced the core slowdown outside Codex Desktop in Node/V8 with the same regex shape used by the composer paste path:

const markdownLink = /\[((?:\\.|[^\]])+)\]\(((?:\\.|[^)])+)\)/g;

Measured results for a JSON-stack-trace-like string:

1200 chars: ~21 ms
1400 chars: ~262 ms
1600 chars: ~1.47 s
1800 chars: >5 s timeout

Measured results with a fixed 2000-character string:

[`... 16 backslash escapes ...]` without `](`: ~207 ms
[`... 20 backslash escapes ...]` without `](`: ~3 s
[`... 24 backslash escapes ...]` without `](`: >5 s timeout
same 40 backslash escapes with valid `](target)`: ~0.04 ms

What is the expected behavior?

Pasting this text should not freeze the composer.

If Codex needs to inspect pasted text for rich links or mentions, that detection should be bounded and should not block the renderer. If the pasted text is too expensive to inspect safely, Codex should treat it as plain text or convert it into a pasted-text attachment.

Additional information

Environment details:

  • macOS 15.7 (24G222)
  • Apple Silicon
  • Bundle ID: com.openai.codex
  • app.asar SHA-256: de59889d6501fc863a825c3e1c05a902ce5e001dff4d1e65474d5ae73768c0ae

The likely root cause is the Markdown link detection regex used during paste handling:

/\[((?:\\.|[^\]])+)\]\(((?:\\.|[^)])+)\)/g

The subpattern (?:\\.|[^\]])+ is ambiguous because a backslash can match both alternatives:

  • \\.
  • [^\]]

When a string contains [ followed by many escaped backslashes or escaped quotes, but does not form a valid Markdown link ](...), V8 spends a long time backtracking.

Making the fallback character classes exclude backslash removes the slowdown in my local reproduction:

/\[((?:\\.|[^\\\]])+)\]\(((?:\\.|[^\\)])+)\)/g

With that safer pattern, the same 4991-character heavy cases complete in about 0.06-0.10 ms.

Possible fixes:

  • Make Markdown link detection regexes unambiguous by excluding backslash from fallback character classes.
  • Add a length/time guard around paste-time rich prompt parsing.
  • Skip rich prompt parsing for stack-trace-like pasted JSON under 5000 characters, or convert medium-sized pasted text to an attachment before running expensive detection.

Workarounds:

  • Paste stack traces as .txt attachments.
  • Paste at or above 5000 characters so Codex converts the content into Pasted text.txt.
  • Decode escaped JSON stack-trace strings before pasting.

View original on GitHub ↗

9 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #25852
  • #25547
  • #25434
  • #25578
  • #25260

Powered by Codex Action

iwbtamkn47 · 1 month ago

I checked the suggested duplicates. They look related, but this report has a narrower repro and points to
the paste-time Markdown link regex backtracking path.

h01d3r · 1 month ago

I hit a related recovery failure mode after a large pasted payload made the composer unusable on session reopen. The important detail: clearing only the Codex session history is not enough, because the VS Code extension can keep/rewrite the stuck composer text from its own persisted state.

Workaround that recovered the affected session without deleting the conversation:

  1. Fully quit VS Code first. This matters: if VS Code is still running, the extension/webview can rewrite the stale composer state back into the DB from memory.
  2. Edit the VS Code global storage DB:
~/Library/Application Support/Code/User/globalStorage/state.vscdb
  1. In table ItemTable, key openai.chatgpt, parse the JSON value and remove:
persisted-atom-state.composer-prompt-drafts-v1["local:<thread_id>"]
  1. Also remove matching large/stuck entries from:
persisted-atom-state.prompt-history["<thread_id>"]

In my case the stuck composer text started with 1) href=..., and deleting only composer-prompt-drafts-v1 did not help because prompt-history restored/reseeded it.

  1. Commit the updated JSON back to ItemTable.value, then optionally run VACUUM on the DB so the raw pasted bytes are physically removed from the SQLite file.
  2. Reopen VS Code.

A minimal Python shape of the recovery is(replace "1) href" with yours prompt starts) :

import json, os, sqlite3

thread = "<thread_id>"
db = os.path.expanduser("~/Library/Application Support/Code/User/globalStorage/state.vscdb")
bad_prefixes = ("1) href=", "1)href=", "1)\u00a0href=")

con = sqlite3.connect(db)
raw = con.execute("select value from ItemTable where key='openai.chatgpt'").fetchone()[0]
if isinstance(raw, bytes):
    raw = raw.decode("utf-8")

data = json.loads(raw)
state = data.setdefault("persisted-atom-state", {})
state.setdefault("composer-prompt-drafts-v1", {}).pop(f"local:{thread}", None)

hist = state.setdefault("prompt-history", {})
for key, items in list(hist.items()):
    if isinstance(items, list):
        hist[key] = [s for s in items if not (isinstance(s, str) and s.startswith(bad_prefixes))]

con.execute(
    "update ItemTable set value=? where key='openai.chatgpt'",
    (json.dumps(data, ensure_ascii=False, separators=(",", ":")),),
)
con.commit()
con.execute("vacuum")
con.close()

This is only a local recovery workaround, not the root fix for the paste-time freeze, but it should help affected users recover a session while preserving the conversation.

unicbm · 1 month ago

Adding a Windows datapoint that appears to be the same paste-path bug, with an additional recovery clue.

Environment:

  • Windows 10.0.26100 x64
  • Codex Desktop package path version observed in recovery notes: 26.602.4764.0
  • Trigger: escaped Tailwind/CSS selector beginning with #simulation-result, containing \[, \], \,, \:, \(, \., Tailwind arbitrary value classes, and > combinators.

Observed:

  1. Paste the selector into the new-conversation composer.
  2. Codex Desktop freezes / becomes unusable; the visible editor may appear empty.
  3. On restart, the app hydrates the same bad draft and can remain slow or stuck.
  4. The pasted text was persisted under:

electron-persisted-atom-state.composer-prompt-drafts-v1.new-conversation

  1. Removing only that stuck composer draft from .codex-global-state.json / .codex-global-state.json.bak restored the app without touching local sessions.

This suggests the paste parser can freeze before or during autosave, and then the persisted draft re-enters the expensive path on restart. Besides fixing the paste-time regex/backtracking path, Codex should avoid synchronously hydrating persisted composer drafts through the same unsafe rich parsing path, or should timeout/drop/attach drafts that match this unsafe case.

Workaround/recovery:

  • Save the selector into a .txt file and ask Codex to read it.
  • Remove CSS escaping before paste when exact selector syntax is not required.
  • Recovery is to stop only the desktop app, back up global state, and remove the stuck composer draft entry containing the selector fingerprint. Do not delete sessions/auth/config/state DB.
9speedeyeball · 1 month ago

Adding another macOS datapoint that appears to be the same paste-time composer freeze.

Environment:

  • Codex App: 26.602.40724 (3593)
  • Bundled Codex CLI: codex-cli 0.137.0-alpha.4
  • macOS: 15.0 (24A335), arm64
  • Reproduced on another coworker's machine: yes

Observed:

  1. Open Codex Desktop.
  2. Start a new chat/thread.
  3. Paste the payload below into the chat composer.
  4. The app freezes immediately, before submitting the message.
  5. Repro rate: 100%.

This payload is small and contains nested escaped JSON inside the messageContent string, so it does not look like a large-paste or history-size issue.

Payload:

[{"id":"1b6d37deeaa94d82ab58513dccde61e9","data":{"messageId":"210d1fedcdc449f09d49c5be61c0022c","messageContent":"{\"status\":\"SUCCESS\",\"subName\":\"invokeProxy\",\"component\":\"CommonMessage\",\"serviceId\":\"none\",\"componentProps\":{\"messageData\":[{\"type\":\"markdown\",\"content\":\"Ok, I've stoppen generating the response\"}]}}"}}]

The specific pattern here is a JSON array with a messageContent field whose value is itself a JSON string with many escaped quotes and nested componentProps.messageData content.

Gulitter · 1 month ago

I hit what appears to be the same paste/composer freeze on Windows.

Additional reproduction details:

  • Platform: Windows
  • Codex App version: 26.601.2237.0
  • Surface: Codex Desktop composer
  • Scenario: pasting debugging error logs into a new chat
  • This happens in a new chat, so it does not appear to require large persisted session history or session restoration.

Two examples that triggered the freeze for me:

  1. n8n / ComfyUI JSON error containing a stackTrace array with escaped Windows paths, for example strings like:
{
  "errorMessage": "'bool' object is not callable [line 21]",
  "errorDescription": "5420 (SamplerCustomAdvanced)",
  "n8nDetails": {
    "n8nVersion": "2.21.7 (Self Hosted)",
    "binaryDataMode": "filesystem",
    "stackTrace": [
      "Error: ComfyUI prompt failed at node 5431:5420 (SamplerCustomAdvanced): 'bool' object is not callable",
      "    at VmCodeWrapper (evalmachine.<anonymous>:21:9)",
      "    at result (D:\\\\code\\\\pixi\\\\n8n\\\\node_modules\\\\@n8n\\\\task-runner\\\\dist\\\\js-task-runner\\\\js-task-runner.js:215:61)"
    ]
  }
}
  1. Python / PyTorch traceback output from GPT-SoVITS training, including torch.multiprocessing.spawn.ProcessRaisedException, Windows paths, and nested traceback text.

I originally opened #27135 before noticing this duplicate. Closing that one as a duplicate and leaving this additional Windows repro data here.

picassoboss · 1 month ago

Additional reproduction case — escaped JSON with CJK characters

App version: 0.124.0
Platform: Darwin 24.6.0 arm64 arm

What issue are you seeing?

Same freeze as described in this issue. Pasting a JSON array (~800 chars) containing escaped Chinese address fields into the composer causes immediate UI hang. The renderer CPU spikes to ~100% and the app must be force-quit.

Steps to reproduce

  1. Open Codex Desktop, start a new chat.
  2. Paste the sanitized payload below into the composer.
  3. UI freezes immediately — no recovery without force-quit.

Sanitized repro payload

Sensitive fields (phone, userId, lat/lng, name) replaced with placeholders. The escaped JSON structure and CJK characters are preserved — these are the trigger.

["{\"acceptName\":false,\"addressDetail\":\"某某路100号\",\"area\":\"某某县\",\"bizChannel\":\"Buy\",\"bizEntrance\":\"taobao\",\"city\":\"某某市\",\"defaultDeliverAddress\":false,\"divisionCode\":\"100000\",\"eleAddress\":false,\"forgin\":false,\"frontend\":\"0\",\"Name\":\"测试用户\",\"gAT\":false,\"guoguoAddress\":false,\"id\":0,\"kinshipAddress\":false,\"kinshipUserId\":0,\"language\":\"zh\",\"latitude\":\"30.000000\",\"longitude\":\"120.000000\",\"mobileInternationalCode\":\"86\",\"mobilePhoneNumber\":\"13800000000\",\"needLatLng\":true,\"overSea\":false,\"overseaAddress\":false,\"platform\":\"APP\",\"province\":\"某某省\",\"rarelyUsedAddress\":false,\"skipPoiLocCheck\":false,\"town\":\"某某乡\",\"townDivisionCode\":\"100000200\",\"userId\":1000000000000}", "mtop", "{\"forceMobile\":\"1\",\"supportValidate\":\"0\",\"currentPosition\":\"30.000000,120.000000\",\"version\":\"2.0\",\"needLatLng\":\"true\"}"]

Why it triggers

Matches the root cause in this issue exactly:

  • Starts with [ — the regex enters the Markdown link capture group
  • Contains 30+ \" escape sequences — each creates an ambiguous branch for (?:\\.|[^\]])+
  • No valid ](url) terminator — the engine backtracks exponentially

The CJK characters (某某路, 某某省) add extra bytes per character but are not the primary cause — the freeze reproduces with ASCII-only escaped JSON of similar length as well.

Iberxilong-blackbox · 1 month ago

Add another situation that can also be replicated

critical-text.txt

rafabd1 · 1 month ago

Adding one more Windows datapoint.

I was able to reproduce the slowdown/freeze with a very small user-authored prompt containing escaped backslash sequences inside square brackets, without a valid Markdown link terminator.

Minimal payload that triggered the issue in my local test:

[\\\"\\\"\\\"\\\"\\\"\\\"\\\"\\\"\\\"\\\"\\\"\\\"x]

One useful distinction from my testing: the problematic behavior appears to be on the user/composer/user-message rendering path. The same payload rendered in an assistant response did not trigger the same slowdown locally.

I also isolated the Markdown-link detection pattern and confirmed this reduced payload can exceed 10s in a worker benchmark, while removing either the square brackets or the backslash escape sequences makes it return immediately.

This seems consistent with the catastrophic backtracking explanation already described here.