Bug report: background subagent notification resume sends truncated model slug claude-fable-5

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Summary
When a print-mode (agent -p) session running with --model claude-fable-5-thinking-high launches a background subagent (Task tool, run_in_background=true), the CLI crashes with exit 1 when the subagent’s completion notification arrives. The notification-driven parent resume sends the model name as claude-fable-5 (the -thinking-high suffix is stripped), which the backend rejects:

S: AI Model Not Found Model name is not valid: “claude-fable-5”
The initial agent run itself is unaffected — sessions run for many turns with the full slug. Only the resume request issued after a task_notification event carries the truncated name. The same scenario with gpt-5.3-codex-xhigh works correctly, so the bug appears to be in the fable slug normalization on the notification-resume code path, not in background-task handling generally.

Environment
cursor-agent CLI: 2026.06.04-5fd875e (current; agent update reports “Already up to date”)
OS: Linux (WSL2 Ubuntu, kernel 5.15.167.4-microsoft-standard-WSL2)
Mode: headless print mode (agent -p), --output-format stream-json

Steps to Reproduce

Steps to reproduce
agent -p --force --trust --output-format stream-json
–model claude-fable-5-thinking-high
“Use the Task tool to launch a background subagent (run_in_background=true, subagent_type=shell, do NOT pass a model) with prompt ‘run: sleep 20 && echo done’. After launching it, end your turn immediately by replying LAUNCHED. When its completion notification arrives, reply with one word: FINISHED.” \

repro.jsonl 2> repro.stderr
echo “exit=$?”
Takes ~60 seconds. Reproduces deterministically.

Actual behavior
exit=1
repro.stderr contains: S: AI Model Not Found Model name is not valid: “claude-fable-5”
Last event in repro.jsonl is the task_notification (“status”:“success”). No result event follows — the process dies attempting the post-notification parent resume:
{“type”:“system”,“subtype”:“task_notification”,“task_id”:“…”,“status”:“success”,“title”:“run: sleep 20 && echo done”,“session_id”:“…”,“timestamp_ms”:…}
Expected behavior
After the background subagent completes, the parent is resumed with the same model it was started with (claude-fable-5-thinking-high), responds FINISHED, and the process exits 0 with a final result event.

Control case (passes)
Identical command with --model gpt-5.3-codex-xhigh:

exit=0, empty stderr
Final event: {“type”:“result”,“subtype”:“success”,“is_error”:false,“result”:“LAUNCHED…The subagent has completed.”,…}
Notes
The truncated name never appears in the stream-json event log — only on stderr at death — indicating the mangling happens inside the CLI’s notification-resume request, not in agent-visible content.
The full slug is valid: agent models lists claude-fable-5-thinking-high, and the parent’s initial turns run fine with it.
Impact: any long-lived headless run using a fable thinking slug that launches a background subagent is marked failed (exit 1) even though its work completed, since the crash happens during the final wrap-up after the notification.
Repro artifacts are in /tmp/fable-repro/ (repro.jsonl, repro.stderr, plus repro2.* for the passing control) if you want to attach the raw logs.

Operating System

Linux

Version Information

2026.06.04-5fd875e

Does this stop you from using Cursor

Yes - Cursor is unusable

Affects all Claude thinking slugs, not just fable: claude-4.6-opus-high-thinking → rejected as claude-opus-4-6. GPT slugs unaffected.

hey @greenham13 thanks for the super detailed repro, this looks like the same resume-after-background-subagent bug family as this thread Multitasking doesnt work with AWS bedrock models , but with Claude thinking slugs getting truncated on the notification resume path.

hi @greenham13 This looks like a CLI issue we fixed after your 2026.06.04-5fd875e build

Could you update the Cursor CLI, confirm the new version, and retry the repro?

cursor-agent update
cursor-agent --version

If it still reproduces on the latest CLI, please share the updated version and stderr output and we’ll take another look.