[FEATURE] Interruptible pause/wait tool with visible countdown

[wthrbtn]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

When Claude Code needs to wait before retrying a command (e.g. waiting for a build to finish, a service to start, or a deployment to propagate), it uses sleep N inside the Bash tool. This has two problems:

1. The sleep command blocks with no visual feedback — the user just sees a spinner with no indication of how long the wait will be or how much time is left.
2. The user cannot interrupt the wait. If the thing being waited on finishes early (which the user can see but Claude cannot), there's no way to say "stop waiting and continue" — the user has to sit through the full sleep duration.

This happens frequently during iterative development workflows: waiting for CI, waiting for servers to restart, waiting for processes to complete, etc. Claude often sets conservative wait times (60-90 seconds) and the user is stuck watching a timer they can't control.

Proposed Solution

A native Pause or Wait tool (separate from Bash) that:

• Displays a visible countdown timer in the TUI
• Allows the user to cancel/skip the wait at any time and let Claude continue to the next step
• Optionally allows the user to adjust the remaining time (extend or shorten)

The tool would return whether the full duration elapsed or was interrupted by the user, so Claude can adjust its behavior accordingly.

Alternative Solutions

• Currently the only built-in option is sleep N via the Bash tool. The user can ctrl+c to kill the bash command, but this doesn't cleanly signal "continue with your next step" — it registers as a failed command. There's no way to communicate "the wait is over, proceed."
• MCP-based sleep tools exist (mcp-wait-timer, mcp-sleep) which are agent-callable, but they are silent backend pauses with no user-facing UI and no way to interrupt or skip the wait. They solve half the problem (the agent can wait) but not the other half (the user can't see or control it).

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

1. User asks Claude to deploy an app and verify it's running
2. Claude runs the deploy command, then needs to wait for the service to come up
3. Claude calls Pause(duration=60, reason="Waiting for service to start")
4. The TUI shows: ⏳ Waiting for service to start... 34s remaining [Press Enter to skip]
5. User sees the service is up after 15 seconds and presses Enter
6. Claude immediately continues to the health check step instead of waiting the remaining 45 seconds
7. Retry workflow: Claude runs kubectl rollout status and it's not ready yet. Claude calls Pause(duration=30, reason="Waiting before checking rollout status again"). The user sees the pods come up after 10 seconds, hits Enter, and Claude immediately re-runs the check — instead of the user watching a dead sleep 30 in Bash.

Additional Context

• Issue [FEATURE] Add /wait Command for Scheduled Execution #7244 proposed a /wait command but was closed as NOT_PLANNED. That proposal was for a user-invoked scheduling command (/wait HH:MM). This request is different — it's for an agent-callable tool with an interactive countdown in the TUI, designed for "wait then retry" workflows during agentic task execution.
• No major AI coding agent (Cursor, Windsurf, Aider, Cline, Copilot CLI, Devin, Jules, Amazon Q, OpenHands, Continue) currently ships a native interruptible wait tool. OpenHands had a draft PR for a WaitAction that was closed without merging. This appears to be a novel capability gap across the ecosystem.