[Bug]: Codex custom-provider replies truncated despite full text in item/completed

[RodriMora]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Summary

When using Codex with a custom provider routed through CLIProxyAPI to a local model, T3 can persist only the first few characters of an assistant reply even though Codex's item/completed notification contains the complete text.

Confirmed by comparing the T3 database with native and canonical provider logs:

Model	Text persisted in T3	Completed assistant text received by T3
GLM-5.3-Flash	Hi! I (5 characters)	142 characters
Babel-LLM	I (1 character)	3,301 characters

An earlier Babel-LLM greeting was persisted correctly, so this does not affect every response.

Steps to reproduce

Observed setup:

1. Configure a custom Codex provider instance using a separate Codex home.
2. Route it through CLIProxyAPI with wire_api = "responses".
3. Select GLM-5.3-Flash or Babel-LLM and send a message. A GLM greeting triggered the issue; it also affected a longer Babel answer.
4. Compare the saved assistant message with item/completed.params.item.text in the provider logs.

The upstream trigger is intermittent. A minimal regression-test event sequence would be:

1. Stream an assistant text prefix such as Hi! I.
2. Complete the same assistant item with Hi! I'm Codex, ready to help..
3. Assert that the persisted assistant message contains the full completion exactly once.
4. Cover both a prefix still in the buffer and a prefix already flushed into the projection.

This proposed regression sequence has not yet been added or run as a test.

Expected behavior

T3 reconciles partial streamed text with the completed assistant item and persists the full answer without duplicating text already received.

Actual behavior

Only the prefix is persisted, and the message is marked complete. The rest survives in the provider logs and Codex transcript but is absent from T3's message events and projection. Refreshing the client cannot recover it.

Logs or stack traces

Sanitized excerpts from the GLM case, with identifiers and unrelated fields omitted:

Codex native notification:
  method: item/completed
  item.type: agentMessage
  item.text: "Hi! I'm Codex, ready to help in your `~/dev` workspace. What would you like to work on — exploring code, fixing a bug, building something new?"

T3 canonical event:
  type: item.completed
  payload.itemType: assistant_message
  payload.detail: [the same full 142-character reply]

Persisted orchestration events for that assistant message:
  sequence 82: thread.message-sent, text="Hi! I", streaming=true
  sequence 83: thread.message-sent, text="", streaming=false

projection_thread_messages:
  text="Hi! I"
  is_streaming=0

Likely cause

The Codex adapter preserves the full completion in the canonical event. The loss occurs downstream in assistant-message finalization.

In ProviderRuntimeIngestion.ts, finalizeAssistantMessage prefers any nonempty buffered text over the completion's fallbackText:

const text =
  bufferedText.length > 0
    ? bufferedText
    : (input.fallbackText?.trim().length ?? 0) > 0
      ? input.fallbackText!
      : "";

The completion call site also supplies the fallback only when the existing projected message is absent or empty. These paths leave a nonempty partial stream unrepaired.

Recorded diagnostic probes suggest an upstream trigger involving interleaved reasoning and assistant output from CLIProxyAPI: with reasoning summary auto, Codex emitted a short assistant delta but later completed the item with the full text. A probe with summary unset streamed the full greeting. This is a suspected proxy/Codex interaction, not an established universal trigger. Regardless, T3 already has the full completion available to recover the answer.

Impact

Major degradation or frequent failure. Substantial answers can appear as a single character.

Version or commit

Source inspected at b2b43bef73447c483ceae486890cb79f01c369cb. The exact T3 build that wrote the affected history was not independently established.

Environment

Linux host; Codex app-server; custom Codex home; CLIProxyAPI Responses endpoint; GLM-5.3-Flash and Babel-LLM. Recorded diagnostic probes used Codex CLI 0.155.1.

Workaround

The full answer can be read from the provider log or Codex transcript. No reliable configuration-only workaround has been established for T3.

Related

#7137 reports a similar first-delta-only symptom in the Claude adapter. This report concerns the Codex path, where the canonical item.completed event already contains the complete text, but shared ingestion fails to recover it.

[juliusmarminge]

Confirmed on b2b43bef. The Codex adapter is doing the right thing. item/completed agentMessage.text is the full message (AgentMessageThreadItem.text in the app-server schema, not a delta). mapItemLifecycle copies that into canonical item.completed payload.detail. The loss is in assistant finalization after that.

Two gates drop a snapshot whenever any prefix already exists. Both match the regression sequence in the report.

1. Prefix still buffered (default responseStreamingMode is paragraph, and Hi! I has no paragraph break, so this is the path that matches the two persisted events). finalizeAssistantMessage takes the buffer and ignores fallbackText whenever the buffer is nonempty:

      const bufferedText = yield* takeBufferedAssistantText(input.messageId);
      const text =
        bufferedText.length > 0
          ? bufferedText
          : (input.fallbackText?.trim().length ?? 0) > 0
            ? input.fallbackText!
            : "";

That emits thread.message-sent with text="Hi! I", streaming=true, then thread.message.assistant.complete, which the decider stores as text="", streaming=false. The projector appends streaming deltas and, on a non-streaming event with empty text, keeps the text it already has. Refresh cannot recover it.

2. Prefix already flushed (token mode, or a paragraph that already spilled). The completion call site only forwards detail when the projected message is missing or empty, so a nonempty prefix never sees the snapshot:

        const shouldApplyFallbackCompletionText =
          !existingAssistantMessage || existingAssistantMessage.text.length === 0;
        // ...
            ...(assistantCompletion.fallbackText !== undefined && shouldApplyFallbackCompletionText
              ? { fallbackText: assistantCompletion.fallbackText }
              : {}),

turn.completed finalizes the same message with no fallback at all, so a later turn boundary does not repair it either.

This is the other side of #465. detail is a full snapshot (Codex item.text, Claude fallbackText, OpenCode latestText). Appending it whenever any text exists duplicates a normal stream. The token-mode test that completes "hello live" with detail: "hello live" depends on that. A fix has to reconcile, not prefer the snapshot blindly:

• accumulated = projected text + still-buffered text
• if detail is a strict extension of accumulated (detail.startsWith(accumulated) and longer), persist only the missing suffix
• if they are equal, or detail is empty, keep today's behavior
• if they diverge, do not replace the streamed text

The no-delta case is already covered (uses assistant item completion detail when no assistant deltas were streamed). The new test should cover both a prefix still in the buffer and a prefix already flushed, and assert the full completion exactly once.

The CLIProxyAPI / reasoning summary = auto interaction is a plausible reason the delta stream stops early. It is not required for the bug: once item.completed.detail holds the full reply, T3 can save it. No settings workaround. The full text remains only in the provider log and the Codex transcript.

Not a duplicate of #7137. There the Claude adapter never attaches the snapshot to the stalled block, so ingestion has nothing to recover. Here the canonical event already has the full text.