[BUG] claude -p with active Agent Team: 'shut down before final response' system-reminder fires every assistant turn, persists after team cleanup, induces premature shutdown (regression introduced in 2.1.126)

Bug Description

A new system-reminder fires repeatedly when a claude -p (non-interactive) session has an active Agent Teams team. The reminder is prescriptive (instructs the model to shut down its team and prepare a final response), continues firing on every assistant turn for tens of minutes, and persists even after the team's on-disk directory is force-removed via rm -rf. On Opus 4.7 this reliably causes premature panic-shutdown ~30 seconds after team creation, before any worker has done meaningful work.

Reminder text (verbatim, repeated 382 times in a single 30-min session):

<system-reminder>
You are running in non-interactive mode and cannot return a response to the user until your team is shut down.

You MUST shut down your team before preparing your final response:
1. Use requestShutdown to ask each team member to shut down gracefully
2. Wait for shutdown approvals
3. Use the cleanup operation to clean up the team
4. Only then provide your final response to the user

The user cannot receive your response until the team is completely shut down.
</system-reminder>

Shut down your team and prepare your final response for the user.

Environment Info

• Platform: linux (Ubuntu)
• Version where regression appears: 2.1.126
• Last working version: 2.1.123 (verified)
• Affected entry point: claude -p (non-interactive / SDK)
• Trigger: any active Agent Teams team (TeamCreate was called and at least one member is registered)
• Model: Claude Opus 4.7 1M context

Reproduction

1. Start a claude -p non-interactive session with a long-running task that requires Agent Teams (e.g., spawn a teammate to do research).
2. Have the parent (manager) call TeamCreate, then spawn a teammate via Agent with team_name.
3. Within ~30 seconds, the system-reminder begins firing.
4. The reminder continues to fire on every subsequent assistant turn, regardless of what the manager does.
5. Even after TeamDelete returns "Cannot cleanup team with active member(s)" and the manager rm -rfs the team folder, the harness still considers the team active and continues injecting the reminder.

Observed behavior on Opus 4.7

The model interprets "shut down your team before preparing your final response" as "shut down right now" — sending requestShutdown to the teammate within 30-60 seconds of team creation. Because the teammate hasn't yet had time to acknowledge the dispatch (let alone start work), it never returns the shutdown_response, leaving the team in a half-shutdown state. The reminder continues firing. The model eventually enters a tight loop generating the same "final response" summary every 2-3 seconds as the harness re-injects the reminder, never escaping.

In our use case (an autonomous heartbeat that dispatches a worker for 30-90 minutes of research, then collects results), this means no work can complete on 2.1.126 — the manager always shuts down its worker prematurely.

Quantitative comparison

Same heartbeat workflow, same prompts, same model, run on different versions:

| Version | Date | Reminder occurrences in transcript |
|---------|--------------|------------------------------------|
| 2.1.121 | 2026-04-28 | 0 |
| 2.1.123 | 2026-04-29 | 0 |
| 2.1.123 | 2026-04-30 | 0 (across 5 separate fires) |
| 2.1.126 | 2026-05-01 | 382 (single 30-min session) |

Counts are distinct user-side injections of the byte-identical reminder text, parsed from the JSONL transcript at ~/.claude/projects/-home-cortex-cortex/{session-id}.jsonl.

Temporal distribution within a single 2.1.126 session

11:08  1   ← first injection, 26 sec after TeamCreate; manager panic-shuts-down here
11:09  -   ← (manager force-cleans team)
11:10  -   ← rm -rf ~/.claude/teams/{name}/
11:21  3   ← reminder resumes
11:22  9
11:23  23
11:24  25
11:25  23
...
11:39  12
11:40  1   ← session exits (timeout, lock held until then)

The reminder is silent during the brief window where the manager is actively trying to clean up, then resumes at ~20-25/minute (one per assistant turn) for the next 17 minutes. Force-removing the team folder on disk does not stop it — the harness's team-state machine is independent of the disk.

What's odd about the reminder text itself

The reminder seems to be operating on a flawed premise. It says: "You are running in non-interactive mode and cannot return a response to the user until your team is shut down." — but in the heartbeat use case, the manager has many minutes of legitimate work to do (monitor worker progress, run readiness gate, apply labels) before its final response. Telling it on turn 1 that it cannot respond until the team is shut down is the wrong framing — the team is supposed to be active during the work, and the manager will shut it down naturally when work is complete.

Workaround

Reverting ~/.local/bin/claude symlink to point at version 2.1.123 fully resolves the issue. Heartbeat runs that previously deadlocked at 30s now complete normally.

Suggested fix paths

1. If the reminder was added intentionally to prevent some real bug — please share the motivation. There may be a less aggressive way to address whatever it was protecting against.
2. If this was unintentional — likely a debug/dev-only reminder that leaked into production — revert that change.
3. Either way: the reminder firing every 2-3 seconds is hostile to any sustained claude -p workflow with Agent Teams. At minimum, fire-once-per-team-state-transition rather than every turn.
4. Reminder text should distinguish "work is complete and you're trying to respond" from "work is in progress, team will be shut down later." The current text conflates these.

Why this matters

Many SDK / claude -p workflows rely on Agent Teams for long-running orchestration where the parent dispatches workers, monitors progress, and handles review-fix cycles. The 2.1.126 behavior breaks all such workflows on the first fire. A workflow that worked perfectly on 2.1.123 simply does not function on 2.1.126.

Happy to share full session transcript JSONL via private channel if useful for debugging.