I Built a Framework on Claude Code. Then Anthropic Changed a Default. Here's How I Defended It. — Blog · mauroepce<br>← HomeOn July 17, 2026, Olaf Alders published "Claude Code: Anatomy of a Misfeature". He documented a silent change in Claude Code v2.1.198. The AskUserQuestion tool (the primary mechanism agents use to pause and wait for human input) started auto-continuing after 60 seconds of user silence, using the model's best-guess answer instead of blocking. No release notes. No opt-out setting. Only an undocumented CLAUDE_AFK_TIMEOUT_MS env var as escape.

Anthropic reverted the default in 2.1.200+. But the episode revealed a class of risk I hadn't accounted for in my own work.

This is a write-up of the defensive pattern I built in response, and why it applies to anyone shipping a framework on top of an AI agent platform they don't control.

Why I noticed

I maintain a personal Claude Code toolkit whose central discipline is human-in-the-loop confirmation at every code-generation gate. Spec review before implementation, explicit confirmation before commit, a second OK before pushing to main, hypothesis capture before investigating a bug. All of those gates share one dependency: they invoke AskUserQuestion to pause the agent and wait for me to approve or redirect.

If that behavior changes (say, auto-continues with a guess after 60 seconds), every gate silently degrades. The user thinks they're being asked. In reality, the agent decided for them.

That's the threat Alders' article documented. The rest of this piece is what I built in response: two standalone defensive scripts, plus the reasoning that ties them into a pattern generalizable beyond my situation. If you want to see the toolkit itself, it's on GitHub, but it's not the point of the article.

The class of risk (not just this bug)

The specific misfeature was reverted, but the pattern it revealed is permanent: any framework built on top of a platform can have its guarantees silently degraded when the platform changes behavior .

Traditional software has a version of this problem: dependency updates break API contracts. But agent frameworks have a newer, sneakier version. The dependency can silently change behavior, not just API. Your code compiles. Your tests pass. Your safety gates appear to still exist. But under the hood, the semantics moved.

Why this matters at every scale

To make the abstraction concrete, here's what a silent auto-continue on AskUserQuestion breaks across three progressively higher-stakes contexts. None of these require Anthropic to reintroduce the exact same misfeature. Any equivalent silent behavior change (a new default timeout, a renamed setting, a semantic tweak that "seemed harmless") reproduces the same class of failure.

Solo developer. Your commit-confirmation step (the one that shows you the diff and asks "commit with this message?") was supposed to pause the agent. You stepped away to take a call. Claude interpreted the silence as approval and committed. The commit landed with a suboptimal message you would have edited. Recoverable, but the review discipline just quietly disappeared.

Team environment. Your push-to-main gate (the one that asks "confirm push to main?" before shipping) was the last checkpoint. You were mid-Slack thread. Claude waited 60 seconds, decided you'd have said yes, pushed. CI kicked off. Your team's convention of "main is protected by explicit human review" became a suggestion, not a rule.

Regulated or high-stakes context. Your CI pipeline's manual approval gate for production deploys was implemented as an AskUserQuestion prompt to the on-call engineer. During a routine change, the on-call was multitasking. The 60-second timeout let the deploy through without explicit human sign-off. If your compliance framework (SOC 2, HIPAA, PCI-DSS, ISO 27001) requires documented human approval for production changes, the auto-continue is no longer just a bug. It's an audit finding. And your organization owns explaining it to the auditor, not Anthropic.

The stance that follows

Once I saw this class of risk clearly, retroactively "trusting Anthropic to be careful" felt like the wrong stance. Not because Anthropic is careless (they're not, and they reverted the misfeature quickly), but because trust-in-vendor is not a defense pattern. Explicit configuration is.

Three defenses

I settled on three configuration values that live in ~/.claude/settings.json. Each one defends against a distinct failure vector:

"askUserQuestionTimeout": "never",<br>"env": {<br>"CLAUDE_AFK_TIMEOUT_MS": "9999999999",<br>"DISABLE_AUTOUPDATER": "1"

Defense 1: "askUserQuestionTimeout": "never"

The official setting Anthropic added in 2.1.200+. Setting it explicitly (rather than relying on the current default) means that if a future version silently ships a new default, my explicit value wins. Even if "never" becomes non-default, my config is unaffected.

Cost: zero. Value: the framework works predictably across version drift.

Defense...