[Feature Request] More descriptive, self-aware status line messages during execution

Preflight Checklist

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

Problem Statement

The #1 reason I use BTW (the interrupt/side-channel feature) is not to add context — it's just to ask "are you still working? What are you doing? Are you hung?"

The current status messages during execution are generic and opaque:

• "Thinking..."
• "Running bash command..."
• "Reading file..."

These tell me what tool is running but not what Claude is actually doing or why. In a long session, "Thinking..." for 30+ seconds gives me zero signal about whether Claude is:

• Planning its next move
• Stuck in a reasoning loop
• About to produce output
• Genuinely hung

The insight: BTW essentially acts as a second thread peeking into the session and reporting status. That capability shouldn't require an explicit user interrupt — the status line should provide that ambient awareness by default.

Three things I constantly use BTW for that the status line should handle natively:

1. "Are you alive?" — Is Claude still working or is it hung? The status line should tell me what it's actively doing.
2. "How much longer?" — Some sense of progress or scope. "Editing file 2 of 5..." or "Running tests (slow — 45s so far)..." gives me a feel for whether I should wait or go do something else.
3. "Are you stuck?" — This is the big one. Sometimes BTW comes back and essentially says "yeah, I'm spinning on this thing and not making progress." Claude should have that self-awareness built in. If it's retrying something, hitting errors, or going in circles, it should proactively surface that in the status line instead of silently grinding. A human colleague would say "hey, I'm stuck on this part" — Claude should too.
4. "Is it me or is it the server?" — Sometimes things are slow not because Claude is stuck, but because Anthropic's servers are under heavy load. Right now there's zero distinction between "Claude is thinking hard" and "the API is backed up." If response times are elevated due to server load, the status line should say so: "Responses slower than usual — high server demand." That one sentence saves the user from wondering if their session is broken.

Proposed Solution

Make status line messages more contextual and self-aware. Instead of generic tool names, surface what Claude is actually thinking about or trying to accomplish:

Descriptive status (what am I doing?):

| Current | Proposed |
|---------|----------|
| "Thinking..." | "Planning approach for auth refactor..." |
| "Thinking..." (30s in) | "Evaluating 3 options for the migration path..." |
| "Running bash command..." | "Running tests — waiting for jest..." |
| "Reading file..." | "Reading auth middleware to understand token flow..." |
| "Editing file..." | "Updating the validation logic in UserService..." |

Progress awareness (how much longer?):

| Current | Proposed |
|---------|----------|
| "Editing file..." | "Editing file 2 of 5..." |
| "Running bash command..." | "Running test suite (38s elapsed)..." |
| "Thinking..." (long pause) | "Long reasoning pass — almost done generating plan..." |

Stuck detection (proactive self-awareness):

| Current | Proposed |
|---------|----------|
| "Thinking..." (60s, no output) | "Having trouble with this approach — considering alternatives..." |
| "Running bash command..." (retry) | "Command failed, retrying with different flags..." |
| Silent loop | "Went back to re-read the file — my first approach didn't work..." |

Server-side transparency (is it me or the server?):

| Current | Proposed |
|---------|----------|
| "Thinking..." (slow, no context) | "Response slower than usual — high server demand right now..." |
| "Thinking..." (API retry) | "Server busy, retrying — this isn't stuck, just queued..." |
| Long gap between tool calls | "API latency elevated — your request is processing, just slower than normal..." |

The client knows the API response times. If a response that normally takes 2 seconds is taking 15, the client has that signal and should surface it. Users shouldn't have to guess whether the problem is Claude's reasoning, their network, or Anthropic's servers.

This is similar to how GitHub Copilot Workspace shows step-by-step status ("Analyzing repository...", "Generating plan...", "Implementing changes to 3 files...") — but richer, because Claude has genuine reasoning it could surface.

Key requirements:

• Status updates should reflect the intent, not just the tool name
• Long "Thinking..." phases should periodically update (every ~10s) with what's being considered
• Progress indicators where scope is known (file 2 of 5, test 3 of 12)
• Proactive stuck detection: If Claude is looping, retrying, or not making forward progress, it should say so unprompted — don't wait for the user to ask via BTW
• Should work across all interfaces (CLI, VS Code extension, web)
• No user action required — this is passive, ambient awareness

Alternative Solutions

• BTW / side-channel query: Works but requires explicit user action every time. High-friction for the most common use case ("are you alive?"). Also, BTW is reactive — you have to notice something feels off and then ask. Proactive stuck detection would catch problems before the user even suspects.
• Per-tab status indicators (#36089): Solves the "which tab is active" problem but not the "what is it doing" problem.
• Conversation title as status (#33416): Too coarse — a title prefix like "[Implementing]" doesn't tell you what is being implemented or if it's stuck.

Priority

High - Affects my daily workflow

Feature Category

CLI commands and flags

Use Case Example

Normal flow:

1. I ask Claude to refactor a large module
2. Status shows: "Reading src/auth/ to understand current structure..."
3. 15 seconds later: "Planning refactor — found 4 files that need changes..."
4. Tool call fires: "Editing AuthService.ts — extracting token validation... (file 1 of 4)"
5. Next tool: "Running test suite to verify changes..."
6. At every point, I know exactly what's happening without asking. No BTW needed.

Stuck flow (the real win):

1. I ask Claude to fix a tricky bug
2. Status shows: "Reading error logs to identify the cause..."
3. 30 seconds later: "Tried patching the handler but tests still fail — re-reading the middleware..."
4. 45 seconds: "This is taking longer than expected — the issue might be in the database layer, investigating..."
5. I now know Claude is stuck and can jump in with context ("hey, check the migration from last week") — without having to type BTW first

Additional Context

Environment:

• Claude Code Version: 2.1.87
• Platform: macOS 26.3.1 (Tahoe)
• Machine: MacBook Pro, Apple M2 Pro, 16 GB
• VS Code: 1.113.0
• Claude Code Extension: 2.1.86

Related but distinct from:

• #36089 (per-tab status indicator — about which tab is active, not what is happening)
• #33416 (conversation name as status — too coarse, title-level only)
• #38580 (docs for "Not responding" indicator — about timeout detection, not progress narration)