[CLI] gpt-5.6-sol intermittently omits terminal `]` in JSON final messages

What version of Codex CLI is running?

Observed on codex-cli 0.144.1, 0.144.2, and 0.144.3 (current version: 0.144.3).

What subscription do you have?

ChatGPT subscription. codex login status reports Logged in using ChatGPT; the exact tier is not exposed by the CLI.

Which model were you using?

gpt-5.6-sol with model_reasoning_effort="xhigh".

What platform is your computer?

Microsoft Windows NT 10.0.22631.0 x64

What terminal emulator and version are you using (if applicable)?

Windows Terminal with PowerShell 7.6.3.

Codex doctor report

Not available: codex doctor --json did not return any output within 30 seconds.

What issue are you seeing?

codex exec intermittently returns an otherwise complete JSON final message with exactly one closing ] missing from the terminal attractiveness.reasons array.

The command exits successfully and writes a completed final message. The response contains the complete thesis, references, claims, attractiveness object, and all reason/evidence entries. It ends with the braces for the reason, attractiveness object, and root object, but omits the array closer immediately before the final two object closers.

Sanitized actual ending:

... "evidence":[{"claimKey":"<redacted>","sourceId":1,"quotedSnippet":"<redacted>"}]}}}

Expected ending:

... "evidence":[{"claimKey":"<redacted>","sourceId":1,"quotedSnippet":"<redacted>"}]}]}}

This is not a regex-based classification. I preserved every invalid final message byte-for-byte using its SHA-256 and replayed it through a string/escape-aware delimiter-stack validator. The validator accepts only this exact shape: root object -> attractiveness object -> reasons array, with one missing terminal ] before the final }}. After inserting that single byte, all 107 accepted samples pass both strict JSON.parse and the application's full production response-schema parser.

Observed evidence:

• 107 exact missing-] response bodies across two independent batch revisions
• 7 in the earlier revision
• 100 in the later revision
• The later revision also had 3 other malformed responses; those are excluded from the 107 count because they do not match this exact repair class.
• 30 bounded-retry executions still ended in parse failure, covering 21 distinct ticker/as-of inputs. Other malformed first attempts recovered on the single bounded retry.
• The first byte-proven occurrence was 2026-07-13 03:46:48 KST (2026-07-12T18:46:48.492Z), SHA-256 06fea334023322976279b0180a7112f1a8eaeef9512d80c5bae63ff3f7d32081.
• The first occurrence in the later revision was 2026-07-13 05:11:12 KST, SHA-256 a8bae5c2ece6008f12c7e85e28d624a69f6a18f08513fecfcd25ea253738a9a9.
• The defect reproduced across CLI versions 0.144.1, 0.144.2, and 0.144.3, so it does not appear to have been introduced by one local CLI update.
• Re-running the same frozen input can return valid JSON, so the behavior is stochastic rather than input-deterministic.
• No MCP server or tool call is involved in the failing final turns.

The local wrapper reads the -o final-message output, trims surrounding whitespace, optionally removes an outer Markdown fence, and then calls JSON.parse. It does not edit content inside the JSON and cannot remove the missing array closer at this position.

What steps can reproduce the bug?

The production prompt contains proprietary source text, so it cannot be attached verbatim. The failure is stochastic, but the invocation shape is:

codex exec `
  -s read-only `
  --skip-git-repo-check `
  --ignore-rules `
  --ephemeral `
  --color never `
  -m gpt-5.6-sol `
  -c 'model_reasoning_effort="xhigh"' `
  -o last-message.txt `
  -

The stdin prompt instructs Codex to act as a single-shot completion backend, not use tools, and return only a nested JSON object. The requested shape ends with an attractiveness.reasons[] array whose entries contain nested evidence[] arrays. Responses are typically 10K-18K characters.

A sanitized prompt outline is:

You are being used as a single-shot text completion backend.
Do not inspect files or run tools.
Return only machine-parseable JSON, with no Markdown fences or prose.

Return an object with:
- thesis: string
- references: array
- claims: array
- attractiveness:
  - tier, rawScore, confidence
  - reasons: array of objects
    - lens, direction, summary, sourceIds
    - evidence: array of { claimKey, sourceId, quotedSnippet }

Run the command repeatedly with a sufficiently detailed input. On affected attempts, codex exec exits successfully, but last-message.txt ends in the malformed shape shown above.

There is no stable thread ID because every invocation uses --ephemeral.

What is the expected behavior?

When the final answer is explicitly requested as JSON, the completed final message should be syntactically valid JSON. At minimum, Codex should not report a successful completed turn whose final text has a single unmatched delimiter.

If the backend cannot guarantee JSON syntax without --output-schema, it would still be useful for the CLI to expose whether this exact text came from the model unchanged or whether a streaming/final-message serialization layer could have dropped the token.

Additional information

This appears related to model structured-output behavior, but the available evidence cannot distinguish the model from the provider/CLI final-message serialization boundary. The output is otherwise complete and contains the final closing braces, which does not look like ordinary length truncation.

This is distinct from:

• #15451, which concerns --output-schema with tools/MCP and malformed YAML/plain-text output.
• #29549, which concerns malformed function-call arguments from a custom vLLM provider.
• #31148, which concerns malformed Responses API stream events being dropped and streams hanging.

This report uses the official ChatGPT-backed provider, makes no tool calls in the failing turn, receives a successful completed codex exec, and observes one specific missing terminal array closer in the final assistant text.

Full prompts and response bodies are not attached because they contain proprietary source material. I can provide additional redacted structural samples, timestamps, SHA-256 receipts, response lengths, and aggregate counts if useful.