How do I stop Claude Code from stopping to ask questions?
By Soumen Sarkar · October 2026
Short answer: Tell Claude Code, in its CLAUDE.md, to state a working assumption and keep going whenever something is unclear, and to stop only before actions that can't be undone. Then give those assumptions somewhere visible to go, so a person can correct them later without the session ever waiting.
Why does Claude Code stop to ask?
Because asking is a sensible default when a person is watching one session. When something is ambiguous, checking first avoids a wrong turn.
When you run several sessions, the same habit means each question parks a session until you come back to its terminal. A five-second answer can cost an hour of idle time, and the more sessions you run, the more of them are waiting at any moment.
What instruction stops it?
An instruction that gives the agent another way to handle an unknown. Put it in CLAUDE.md so every session in the repository reads it:
## When something is unclear
- Look first: the code, this file, and the team's notes.
- If the answer isn't there, choose the most reasonable option and write
one line: "Assuming <X> because <reason>." Then keep going.
- If the assumption touches data, money, access, a public interface or
deleting something, mark it "High stakes" and pick the option that is
easiest to reverse. Keep going.
- Stop and ask only before an action that can't be undone.
- List every assumption in your final message.
The key is the last two rules of the middle: the agent is told what to do instead of asking, not just told not to ask. Without an alternative, it either asks anyway or guesses without saying so, which is worse.
What does this look like in a session?
A session is adding a CSV export to Reports · lib/reports. Two things are unclear: which date format to use, and whether archived projects belong in the export.
Before the instruction, it asks about the dates and waits. After it, the session writes:
Assuming ISO 8601 dates (2026-10-14) because spreadsheets parse them
in every locale.
Assuming archived projects are left out because the on-screen report
hides them.
and finishes the export. When you check in, you read two lines. The first is right. The second is wrong, because finance needs archived projects for year-end, so you correct it and the change is a single filter.
Where should the assumptions go?
Somewhere you will actually see them. At minimum, the session's final message and the pull request description. Better, one place across all sessions, so a teammate who knows the answer can correct it without opening your terminal. The assumption line template gives a format every agent can follow.
With Campfyrr connected, the agent states each one with a tool call. If the team's record already answers it, the answer comes back at once. If not, it goes to the right person, and a correction reaches the session at its next turn.
Won't it guess wrong sometimes?
Yes, and that's fine. A stated assumption is cheap to correct because everyone can see it. The real risk is a silent guess, or a session that waits all afternoon for an answer it could have assumed. This is turning unknowns into calls.
Words used here
- Assumption: An assumption is the best available answer to an unknown, stated and acted on, kept visible so anyone can correct it.
- High-stakes assumption: A high-stakes assumption is an assumption that touches data, money, access, public interfaces or deleting things, so being wrong costs more and it should be checked first.
- Correction: A correction is the fix to a wrong assumption or call, made by someone who knows better and sent back to the work that relied on it, without stopping anyone.
The principle behind this: Turn unknowns into calls: Nothing we don't know gets to stop us. We name our assumption, and we move.
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).