Feature request: --wait-on-usage-limit flag for non-interactive / remote-control sessions
Problem
When running Claude Code via /remote-control (e.g. from the mobile app), hitting the usage limit causes an interactive prompt to appear on the local terminal. This prompt blocks the session indefinitely and cannot be dismissed through the remote control channel.
For mobile app users, this means the session is permanently stuck until someone physically accesses the computer — there is no way to recover remotely.
Requested Feature
Add a flag (e.g. --wait-on-usage-limit) that, instead of showing an interactive prompt when the usage limit is reached, silently waits until the quota resets and then automatically continues.
claude --dangerously-skip-permissions --wait-on-usage-limitUse Case
- User runs Claude Code on a desktop/server with
/remote-control - User connects and controls the session from the Claude Code mobile app
- Usage limit is hit mid-session
- With the current behavior: session blocks, mobile app is frozen, physical access required to recover
- With
--wait-on-usage-limit: session pauses silently, resumes automatically when quota resets, mobile app stays connected
Why This Matters
Remote control + mobile is a first-class use case. The current behavior makes unattended or long-running remote sessions impractical because a single quota hit requires physical intervention.
Workarounds Attempted
- Wrapping in a
while truerestart loop — doesn't help because Claude doesn't exit on usage limit, it blocks timeoutwrapper — kills the process, but the mobile app cannot reconnect without re-pairing (physical access needed)- Redirecting stdin from
/dev/null— may cause exit instead of block, but reconnection still requires physical access
None of these fully solve the problem for the mobile app remote control scenario.
Showing cached comments. Read the full discussion on GitHub ↗
10 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This feature request is about hitting usage limit while using /remote-control.
Bump, still having this problem
I keep hitting this issue. Was out of town for a few days and wanted to work on a project remotely. Hit usage limit the first night and didn't have a way to resume until I physically got bask to the machine.
Adding a noise comment to prevent this from being closed.
Adding a noise comment to prevent this from being closed.
Adding a noise comment to prevent this from being closed.
Adding a noise comment to prevent this from being closed.
This is exactly the gap I ran into too — a
while truerestart loop doesn't help, because Claude blocks on the limit instead of exiting, so there's nothing to restart.I ended up building an open-source wrapper for the CLI side of this: claude-ac (https://github.com/blackstardigitalstudio/claude-auto-continue, MIT). Instead of a native flag, it wraps the Claude Code CLI, reads the output, recognizes the usage-limit message, waits for the quota to reset, and relaunches with
--continueautomatically — so you runclaude-ac "your task"and there's no interactive prompt to get stuck on and no physical access needed to recover.Honest caveat: since Claude doesn't emit a Stop event when credits run out, detection is done by reading the output rather than via a hook, so it's a wrapper, not a native
--wait-on-usage-limit. For the desktop-app case there's also an opt-in watcher that clicks the real Resume button via UI Automation (Windows) / Accessibility (macOS) once the quota returns. No telemetry, no open ports, and it never spends money — it only clicks resume.A native flag would still be the cleaner fix, but this has kept my long / unattended sessions from getting stuck in the meantime.
Adding a noise comment to prevent this from being closed.