[FEATURE] Support custom status line in VSCode extension (like CLI's statusline-command)

GitHub Feature Request Draft

Repository: anthropics/claude-code
Label: area:ide, enhancement

---

Title: [FEATURE] Support custom status line in VSCode extension (like CLI's statusline-command)

---

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 Core Request

The CLI supports a powerful statusline-command setting that allows developers to run a custom script and display its output below the input box. This enables each developer to surface the information most relevant to their specific workflow. The VSCode extension lacks this capability entirely.

Why Customization Matters

Every development team has unique workflows, tooling, and information needs:

• DevOps engineers might want to see deployment pipeline status, Kubernetes pod health, or infrastructure state
• Frontend developers might want to see bundle sizes, lighthouse scores, or Storybook build status
• Backend developers might want to see database migration status, API health checks, or cache states
• Mobile developers might want to see simulator status, provisioning profile expiration, or app store review status
• Data engineers might want to see pipeline run status, data freshness, or model training progress

A customizable status line lets each developer—or team—surface exactly the information they need, without requiring Anthropic to anticipate every possible use case.

My Specific Use Case (as an example)

I work on a large codebase using git worktrees, with 6-10 feature branches active simultaneously. With the CLI, I run multiple Claude sessions in terminal tabs, each in a different worktree. My custom status line script shows:

Context & Orientation:

• Worktree name (with color coding - red for main/read-only, green for feature branches)
• Context window usage (percentage with green/yellow/red thresholds at 60%/80%)
• Git branch with ahead/behind counts relative to main
• File changes (staged, modified, untracked counts with line insertions/deletions)

Critical Git Branch Warnings:

The status line instantly alerts me to branch problems that require attention before I attempt to commit or push. These warnings have saved me countless times from making mistakes that would require complex recovery:

| Warning | What it means | Why it's critical |
|---------|--------------|-------------------|
| 🚨 STALE (GitLab rebased and merged) | GitLab performed a server-side rebase before merging my MR. My local branch has different commit SHAs than what's now in main. | If I continue working on this branch and push, I'll create duplicate commits or conflicts. Must create a fresh branch from main. |
| 🚨 DIVERGED (GitLab rebased) | My local branch and origin have diverged because GitLab rebased the remote branch (e.g., during MR pipeline). | Cannot simply push - would fail or create mess. Need to reset to origin or create new branch. |
| 🚨 ORPHANED (rescue work) | The branch has uncommitted changes, but my commits are not in main's history. Something went wrong (bad rebase, force push, etc.) | Uncommitted work exists on a branch that's been orphaned - need to rescue changes immediately before they're lost. |
| ⚠️ MERGED (cleanup ready) | Branch was previously pushed and merged. No new commits ahead of main. | Safe to delete this worktree, but shouldn't add new commits here - create a fresh branch instead. |
| 🚨 TRACKS MAIN (unset upstream) | A feature branch is incorrectly tracking origin/main instead of its own remote branch. | Pushing would fail or push to wrong place. Need to fix upstream tracking before any git operations. |
| ⚠️ N behind (rebase needed) | Branch is significantly behind main (yellow at 6+, red at 21+). | Should rebase before pushing to avoid complex merge conflicts. |

When switching between 6+ worktrees, I cannot remember which branches have these issues. The status line tells me instantly when I switch tabs - before I waste time making commits that will cause problems, or worse, before I accidentally corrupt my git history.

Build/Test/Deploy Pipeline Status:

My development workflow has three distinct validation stages:

| Stage | What it means | Why I track it separately |
|-------|--------------|---------------------------|
| Build | Compile the code | Must succeed before any testing |
| Test | Run unit tests locally | Fast validation of correctness |
| Deploy | Deploy to integration test server | Real-world testing with live dependencies |

Unit Tests vs Integration Tests - Independent Workflows:

• Unit tests (🧪): A comprehensive suite of local tests that validate code correctness. These run quickly and catch logic errors before deployment.

• Integration deploy (🚀): Deployment to a live test server where the code runs with real databases, services, and infrastructure. This catches issues that unit tests cannot.

These are independent validations - the status line shows me exactly which are current and which are stale.

Multi-Server Test Environment:

I maintain multiple test servers (test1, test2, test3, test4, test5, test6, qa) because different features and bug fixes need isolated testing environments. The status line shows exactly which test server received the deployment:

🚀 test3 (12m ago)           # I know test3 has my bug fix code
🚀 test1 (2h ago) ⚠️ DEPLOY NEEDED  # test1 has stale code, needs redeployment

Complete state tracking:

| State | What I see | Why it matters |
|-------|-----------|----------------|
| Code changed since last build | "⚠️ BUILD NEEDED" | Know I need to rebuild before any testing |
| Build succeeded but unit tests not run | "⚠️ TEST NEEDED" | Unit test validation is stale |
| Build newer than last deploy | "⚠️ DEPLOY NEEDED" | Integration test server has old code |
| Deploy failed | "⚠️ DEPLOY FAILED (5m ago)" | Immediately visible deployment problem |
| All green | "🔨 ✓ (2m) 🧪 ✓ (1m) 🚀 test3 (45s ago)" | Full confidence: built, unit tested, deployed to test3 |

What's missing in VSCode extension

The VSCode extension doesn't support the statusline-command hook. When using the extension:

• No way to display custom workflow information
• No context window usage indicator
• No critical git branch warnings (stale, diverged, orphaned, etc.)
• No build/test/deploy status or timestamps
• No project-specific warnings
• No ability to customize what information is displayed

Proposed Solution

1. Support statusline-command in the VSCode extension, identical to the CLI
2. The command would receive the same JSON input (model, session, context window, workspace info)
3. Display the output in a status area within the extension UI (below the input box, like the CLI)

This approach:

• Leverages existing infrastructure - the CLI already has this capability
• Maximizes flexibility - developers customize to their needs without feature requests
• Maintains parity - VSCode extension matches CLI capabilities
• Scales to any workflow - Anthropic doesn't need to anticipate every use case

Alternative Solutions

VSCode status bar extensions were considered, but they show global state, not per-session state. When working with multiple Claude sessions (in separate VSCode windows), each session needs its own status display showing that session's specific context.

Priority

High - Critical for adoption by power users

Feature Category

IDE integration

Additional Context

The CLI's statusline-command is one of its most powerful features for customization. Bringing this to the VSCode extension would enable developers with complex workflows to adopt the extension without sacrificing the situational awareness they depend on.

This isn't about one specific workflow - it's about enabling the same customization capability that makes the CLI so powerful for developers with diverse needs.