[MODEL] Orchestrator launched a six-episode audio re-record after the user had decided to stop regenerating audio; 51 published versions in two days

Status Open
Reported on v2.1.289
Maintainer reply None cached
Activity 0 comments · opened Oct 6, 2026

Preflight Checklist

  • [x] I have searched existing issues for similar behavior reports
  • [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude ignored my instructions or configuration

What You Asked Claude to Do

The user decided the night before to stop regenerating a 12-episode text-to-speech audio guide and to cover known differences with a patch-notes line; on 11:49 the next day the user asked that 'those last couple' be done (episodes 11 and 12).

What Claude Actually Did

  • Published MP3 versions per episode since 04 Oct 22:59 (from the repository history): 4, 3, 5, 4, 3, 5, 4, 5, 5, 3, 5, 5 = 51 in total, i.e. 39 re-publishes, of which about 8 were requested by the user (counted from the user's messages in one transcript, so a lower bound on requests). A helper counted about 79 episode render passes and about 113 retained full-file machine-check reports (lower bounds).
  • On 06 Oct, episodes 3, 6, 8 and 9 were re-voiced at 11:07 (before the user's 11:49 scope message); 11 and 12 at 12:42.
  • A worker was briefed at 12:07 for six episodes (1, 2, 5, 9, 11, 12), and also prepared 3 and 4, because a release check built that morning flagged lines the user had already accepted. It cut back to 11 and 12 only after a new penalty entry arrived mid-run; episodes 1-5 were rendered and machine-checked but not installed.
  • A second overlapping audio worker (for 11 and 12) was started at 11:49 and stopped by the user at 14:04 without voicing anything.
  • The user said to stop at 00:37, but the decision was written to a file only at 12:48 (markdown) and 14:08 (json lock). The check that would have stopped a redo brief did not exist when the six-episode brief went out; it later matched messages that only mentioned re-recording (two false positives).

Expected Behavior

A recorded user decision beats the agent's own checks: a gate flag on something the user accepted becomes an accepted exception, not a re-record. Scope is exactly the items the user asked for, counted one by one.

Files Affected

None. Agent messages and tool calls only.

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

Not a deterministic repro. The sequence is in the record above; the underlying logs are on the reporter's machine and can be summarised on request.

Claude Model

Opus

Relevant Conversation

See "What Claude Actually Did". Quotes are limited to the agents' own tool results and messages.

Impact

Medium - Extra work to undo changes

Claude Code Version

2.1.289 (as recorded in the agent session logs; the claude on PATH reports 2.1.220)

Platform

Other

Additional Context

Related: #99979 (same account) reports the same override of the audio decision; this report adds the per-episode counts.
Single-day record, 2026-10-06, all times US Eastern (Windows 11), a multi-agent session driven through a third-party agent harness; API platform is unverified. Reported as behaviour, not as a claim that Claude Code is defective.

View original on GitHub ↗