Claude Code idle too long between tasks: 4 causes and fixes
When Claude Code sits idle between tasks, it’s almost always one of four things: it’s waiting on you at a permission prompt or a question, it finished and you missed it, it hit a usage limit, or the current tool call is genuinely slow. Each has a different tell and a different fix. Here’s how to tell which one you’re looking at, so you stop alt-tabbing between terminals to guess.
Key takeaways
- Idle is four states, not one: waiting on you, finished unnoticed, stopped on a usage limit, or a long tool call.
- A 30-second look at the spinner, the last line of output and whether anything has scrolled tells them apart.
- Pre-approve safe, repetitive commands in
settings.json. Never pre-approve anything destructive. - Name the files, the steps and what “done” looks like before you walk away, so Claude has nothing to ask.
- With several sessions open, an alert is only useful if it says which session and what state.
What does “idle” actually mean?
Claude Code stops talking when it stops working, and from across the room every stop looks the same.
| idle state | what’s happening | what it costs you |
|---|---|---|
| waiting on you | a permission prompt or a question, often a minute into the run | the whole run, until you answer |
| done, unnoticed | the task finished while you were away | minutes you could have spent reviewing |
| usage limit | you hit your plan’s limit and the run stopped | time until the reset; no prompt fix helps |
| long tool call | a big test suite or build is running | nothing, as long as you know it’s working |
Telling them apart matters because the fixes don’t overlap. A better prompt won’t fix a usage limit, and a settings change won’t make a build faster.
With one session, a missed stop wastes one run. With four open, “something needs you” is half an answer: you still have to find which terminal. That’s the problem I built Exit·0 for, and the story is in how it was made.
How do you tell finished from waiting from stuck?
Check three things, in order:
- Is the spinner running? A spinner with a ticking timer means the turn is still going. A long tool call looks like this, and it’s fine.
- What’s the last line? A summary and an empty prompt box means it finished. “Allow npm install?” means it stopped at a permission prompt and has been idle since. A usage-limit message with a reset time means it’s the plan, not the prompt.
- Has anything scrolled in the last two minutes? If the spinner is moving and output is growing, leave it.
Each state wants something different from you. A finished run wants a review and the next task. A permission prompt wants a yes, or a settings change so it never asks again. A usage limit wants nothing but time.
Exit·0 tells you which session finished, broke or needs you. A permission prompt shows as NEEDS YOU. If a run stops on a usage limit, you get CRASHED. NOT YOUR FAULT. with “rate limited”, so you know not to rush back. A long tool call sends nothing, which is right: it’s still working. One gap: if Claude asks a question in its reply instead of a prompt, the turn ends, so it arrives as a Done. Read the summary.
Which prompt habits make Claude Code stop and ask?
Vague scope. “Refactor the auth module” can be read two ways, so Claude stops to ask which one you meant. Name the files, the pattern and what “done” looks like before you walk away.
Oversized tasks. A 20 to 60 minute task usually stalls mid-plan, not mid-code. Split it into steps Claude can finish and check on its own: “write the failing test, then fix it, then run the suite.” Each step is something it can complete, not a decision it has to hand back to you.
Constraints left out. Put versions, style rules and forbidden actions in the prompt or in CLAUDE.md, not in follow-up messages. Every constraint you leave out is a question waiting for you at minute three.
How do permission prompts create idle gaps?
You hand Claude Code a 20-minute task, switch windows, and it stops at a permission prompt one minute in. Nineteen of the twenty minutes are gone. This is the most common cause, and the cheapest to fix, because the fix is configuration.
Pre-approve what’s safe. Add the commands your runs use every time, such as npm install, your test runner, git status and git diff, to permissions.allow in settings.json. Rules look like Bash(npm run test *). The permissions documentation has the full syntax. For trusted work, --permission-mode acceptEdits approves file edits and simple file commands such as mkdir and mv, while other shell commands still ask.
Keep the dangerous ones gated. Never pre-approve anything destructive or outward-facing: rm -rf, git push --force, curl piped to a shell, or anything that touches production credentials. Those prompts are the gates doing their job.
Review the list. Allowlists drift. A command you added in a rush is still there next month, so look over the list now and then.
If you’d rather wire your own alert than install an app, the hook-script comparison has a two-hook example.
When is it a usage limit, not the agent?
The tell is the message. A permission prompt stops at a specific step and asks you something. A usage limit stops the run with a message saying when your limit resets. If several sessions stop at about the same time, they’ve all drawn on the same plan.
Your levers, cheapest first: move heavy runs away from your busiest hours, run two or three sessions instead of six so they don’t drain the same allowance, or change plan. A run that stopped on a limit doesn’t pick itself up again. Prompt it once the limit resets.
What should an alert tell you?
Two things, the moment you look up: which session, and what state. Still running, finished, failed, or waiting on you. Anything less sends you back to alt-tabbing.
Hook scripts are free and you control every line, but you maintain them, and a plain one can’t tell a finished run from a failed one.
Menu bar apps sit one glance away and can show every session at once.
Phone alerts cover the coffee break, which is where most of the lost time goes.
Exit·0 is a Mac menu bar app with an iPhone app. It shows every session in a run list and tells you when one finishes, breaks or needs you, and when you walk away, your iPhone gets it instead. It won’t fix the permission settings or the prompt that caused the stop, and it won’t answer the prompt for you. That part is still yours.
What does a day without babysitting look like?
Morning: five minutes of setup. Look at yesterday’s permission prompts and allowlist any safe ones that came up repeatedly. Write the day’s tasks as a queue, each with its own “done” condition, so a finished session can move to the next one without asking. Turn your alerts on before you open the first terminal.
The coffee-break loop. Hand off clearly: the task, what done looks like, and what to do if blocked. Then leave. When you’re told something needs you, go straight to that session, fix the prompt or the permission, queue the next task and walk away again. Each prompt you allowlist in the morning is one you don’t answer at 3pm.
FAQ
Why does Claude Code sit there after finishing instead of starting the next task?
It has no queue. A run ends when the prompt in front of it is done. Give it a task file with numbered steps and a “done” condition for each, so one step can lead into the next without a question.
How do I know if I hit a usage limit or it’s waiting on me?
Read the last line. A permission prompt or a question names a step and asks you something. A usage limit stops the run with a reset time. Several sessions stopping at once points to the limit.
Can my phone tell me when a Claude Code session needs input?
Yes. A hook script can send a push if you maintain it. Exit·0 sends NEEDS YOU to your iPhone when you’ve walked away from the Mac, along with the project folder name so you know which session.
Is it safe to let Claude Code run commands without asking?
Partly. Pre-approve safe, repetitive commands in permissions.allow, and use acceptEdits for trusted work. Never pre-approve anything destructive or outward-facing.
Does Claude Code give up if I leave it idle too long?
No. A permission prompt or a finished turn waits until you come back, however long that is. The cost is your time, not the agent’s patience, so knowing the moment it stops is worth more than any timeout.