HTTP 400 `content[].thinking` after a background shell completion notification

The bug is in the runtime's message synthesis path for shell-completion notifications. Look for code that constructs assistant messages with 'toolRequests' but without 'reasoningBlocks' and 'reasoningOpaque'. Start by searching the codebase for 'system.notification' and 'Shell command'. Examine how assistant turns are built when a background shell completes. The fix must ensure thinking-mode fields are preserved or the request builder handles thinking-less turns correctly. Run existing tests related to shell commands and notifications to verify the fix.

Describe the bug

Bug report: HTTP 400 content[].thinking after a background shell completion notification

Summary

When a background shell command outlives its turn and completes, the runtime delivers a
system.notification("Shell command ... has completed") at the start of a new turn. The
assistant message synthesized for that turn is persisted without its thinking blocks, so
the next request replays an assistant turn that has toolRequests but no reasoningBlocks
while thinking mode is enabled. The upstream API correctly rejects it.

Environment

• CLI: GitHub Copilot CLI 1.0.88 (latest; copilot update reports no newer release)
• Model: deepseek-flash
• OS: linux (x64)
• Interactive session, tools enabled

Note: the CLI logs unknown token count multiplier {"model_id":"deepseek-flash"} at startup;
the bundled changelog.json contains no DeepSeek entries at all.

Exact error

{
  "type": "session.error",
  "data": {
    "errorType": "query",
    "message": "400 The `content[].thinking` in the thinking mode must be passed back to the API.",
    "statusCode": 400
  }
}

Evidence

Across every session on this machine (~/.copilot/session-state/*/events.jsonl):

Metric	Count
assistant.message events with reasoningBlocks	582
assistant.message events without reasoningBlocks	8
session.error with statusCode: 400 (this message)	8

Exactly 1:1. In all 8 cases the failing request is immediately preceded by one of the
8 degenerate messages, and in all 8 cases the degenerate message is immediately preceded by a
shell-completion system.notification.

The single non-400 session.error in the corpus ("Session host did not acknowledge ...") is
preceded by a normal 12-key assistant message, which is a useful negative control.

Shape comparison

Normal streamed assistant message (31 of 32 in the interactive session):

['apiCallId','content','interactionId','messageId','model','originatingMessageId',
 'reasoningBlocks','reasoningOpaque','reasoningText','rte','toolRequests','turnId']

Synthesized message that triggers the 400 (1 of 32):

['content','messageId','toolRequests']        <-- reasoningBlocks + reasoningOpaque MISSING

Minimal reproduction

tool.execution_complete    # background shell finishes
assistant.turn_end
assistant.turn_start       # new turn
system.notification        # "Shell command \"<desc>\" (shellId: N) has completed successfully."
assistant.message          # {content:"", messageId, toolRequests}  <-- no reasoning fields
session.error              # 400 The `content[].thinking` in the thinking mode must be passed back to the API.

Concrete instances observed (all identical in structure):

• session 67c30607-7606-4666-aa94-ba687b57f22d, event index 203 → 400 at 2026-09-23T00:06:52.455Z
  (foreground shell id 5 completing was the notification source)
• session a8233a5c-4e04-457a-ab70-950ef0aaf4c3, event indexes 337, 546, 570, 623, 653, 700, 745
  → 400 at 2026-09-22T23:31:20, 23:47:53, 23:48:28, 23:50:46, 23:51:25, 23:52:43, 23:55:02

Reproduction is highly reliable: 8 triggers, 8 failures, 0 misses.

Root cause

The 400 is not an upstream/model outage. The API is enforcing a documented thinking-mode
contract: when thinking is enabled, the thinking block returned with an assistant turn must be
replayed verbatim on subsequent requests (it carries an opaque signature). The runtime drops
reasoningBlocks / reasoningOpaque on the code path that synthesizes the assistant turn for a
shell-completion notification, then replays that thinking-less turn while thinking is still on.

Because the synthesized message also lacks model, apiCallId, turnId and interactionId,
it is clearly produced by a different (non-streaming) construction path than normal model output.

Impact

Every occurrence kills one turn with an opaque 400, in the middle of otherwise healthy sessions.
Recovery requires the user to re-prompt ("continue") or abandon the session. It is most likely to
hit long autonomous runs that rely on backgrounded commands, which is exactly when it is most
disruptive.

Suggested fix

Whichever internal path constructs the assistant message for a shell-completion
system.notification must carry the turn's reasoningBlocks and reasoningOpaque through to
the session event, so the replayed transcript stays consistent with thinking mode. Alternatively,
the request builder should not send a thinking-less assistant turn while thinking is enabled
(e.g. drop thinking for that request rather than emitting an invalid transcript).

Workarounds (user side)

1. Avoid shell commands that outlive the turn (no backgrounded/detached work), so no
   completion notification lands at the start of a new turn.
2. --reasoning-effort none / effortLevel: "none" in settings.json removes the thinking-mode
   requirement. Caveat: for models the CLI classifies as adaptive-only, turning thinking off only
   lowers reasoning effort, so this may not eliminate the failure.
3. Start a new session (/new) to drop the poisoned transcript — recurrence is expected, since
   the trigger is not history-dependent.
4. Report with /feedback and attach /collect-debug-logs.

Non-fixes (checked)

• Rollback: no release in the bundled changelog.json contains a fix for this bug class
  (0 hits for reasoning-block persistence; the only thinking-shape fixes are Claude/Anthropic
  specific and predate 1.0.80). 1.0.86 is still in ~/.cache/copilot/pkg/linux-x64/ if a
  regression test is wanted. Neither app.js nor runtime.node contains the error string, so
  the message is generated server-side.
• copilot update: already on the latest release (1.0.88).

Affected version

GitHub Copilot CLI 1.0.88

Steps to reproduce the behavior

normal cli session which backgrounds. see description.

Expected behavior

no 400 error

Additional context

No response