[Fable 5] Agent treated a scoping question as authorization for a multi-hour autonomous run, ignoring an explicit repo instruction to confirm first

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 2, 2026

Agent treated a scoping question as authorization for a multi-hour autonomous run, ignoring an explicit in-repo "confirm before big moves" instruction

Product: Claude Code (VSCode extension)
Model during the incident: Fable 5 (claude-fable-5, 1M context) — see below
Date: 2026-08-01/02
Severity: High — burned hours of paid tokens on unrequested work

Model

The entire unauthorized run happened under Fable 5.

The session began on Opus 5, was switched to claude-fable-5[1m] via /model,
and remained on Fable for the whole incident: the unrequested ingest, the hours
of hand-authored artifacts, and the four interrupts needed to stop it. It was
switched back to opus[1m] only afterwards, during cleanup.

Flagging this because the behavior may be model-specific rather than a general
Claude Code issue. The same session, on Opus, had been asking before acting.

What happened

I was discussing scope with the agent: which book to start with. I said my
existing finished novel was a better starting point than the unfinished one,
because it's already written and would give a full-novel comparison.

That was a scoping remark. It was not an instruction to begin a pipeline run.

The agent immediately launched a full ingest of the 54-chapter manuscript, then
spent hours hand-writing 54 chapter cards, a story bible, and annealing-judge
verdicts itself — servicing 56 generation prompts by hand — while reporting
this as the program having "really run it."

I had to interrupt four times to stop it.

Why this is a bug and not just a bad judgment call

My repo carries explicit instructions the agent had already read and was quoting
back to me earlier in the same session:

  • CLAUDE.md (user-global): points every session at START-HERE.md before any

book work

  • START-HERE.md §8 House Rules: **"Confirm intent before big pipeline moves —

don't guess."**

The agent had read both files in this session. It quoted §8 to me. It then made
the single largest pipeline move of the session without confirming, and never
checked in at any point across hours of work.

It also wrote its own summary of the work into my repo describing the session
lane as the program generating, when in fact the agent was hand-authoring every
artifact. That is precisely the failure mode my instruction file exists to
prevent, and the agent restated the rule while breaking it.

Expected

Treat a scoping discussion as scoping. Before starting a long-running,
token-expensive pipeline, confirm — especially when the repo contains a standing
instruction to do exactly that.

Actual

Hours of unrequested autonomous work, four user interrupts required to halt it,
and the work reported as compliant with a rule it violated.

Notes

  • No data was lost or corrupted; the agent's file operations were sound and

everything was committed.

  • The problem is purely authorization and scope: sustained autonomous action

without consent, against an explicit written instruction to seek it.

  • The agent self-reported this failure accurately when challenged, which suggests

the issue is not detection but the absence of any check before or during
the run.

Suggested

A long-running agent should re-check authorization when work greatly exceeds the
scope of the request — not only at the start. There was no point in several hours
where it paused to ask whether this was still what I wanted.

If this is Fable-specific, it is worth checking whether that model weights
"keep making progress" over "stop and confirm" more heavily than Opus does. The
instruction it needed to follow was one line, in a file it had already read and
quoted, and it still ran for hours without a single check-in.

View original on GitHub ↗