Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] Terminal Mode startup delay: shellIntegration.executeCommand waits ~5s for OSC 633 prompt markers before typing `claude`

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Follow-up to #26849 (closed/locked, @Rylon) — same case, now with a root cause and a measured workaround.

In "claudeCode.useTerminal": true, after the terminal opens there's a multi-second gap before the claude command is typed. I traced where it actually goes.

Root Cause

The extension calls terminal.shellIntegration.executeCommand("claude") as soon as shell integration is reported available (~0.6s). But executeCommand then waits for the shell's OSC 633 prompt-ready markers before writing the command. On my setup those markers arrive ~5s after the prompt is already accepting raw keystrokes — so:

  • I can type into the terminal immediately, but
  • the injected claude only lands at +5–6s, appended after anything I typed (the keystroke-append issue, cf #18779).

My ~/.zshrc sources in 0.13s (time zsh -i -c exit), so this is the first interactive prompt / shell-integration handshake, not rc cost.

Fix Action

Fix / Workaround

Summary

Follow-up to #26849 (closed/locked, @Rylon) — same case, now with a root cause and a measured workaround.

Workaround (confirmed −2s)

Set "terminal.integrated.shellIntegration.enabled": false. The executeCommand path is skipped, the extension falls back to its hard-coded 3000ms sendText path, and launch drops from ~5.5s to a stable ~3.4s (3/3 runs). The log no longer shows "Terminal shell integration available".

Code Example

Creating new Claude terminal
Terminal shell integration available      (+0.6s)   <- executeCommand("claude") called here
New WS connection from: /                 (+5.5s)   <- claude finally launched & connected
RAW_BUFFERClick to expand / collapse

Summary

Follow-up to #26849 (closed/locked, @Rylon) — same case, now with a root cause and a measured workaround.

In "claudeCode.useTerminal": true, after the terminal opens there's a multi-second gap before the claude command is typed. I traced where it actually goes.

Root cause

The extension calls terminal.shellIntegration.executeCommand("claude") as soon as shell integration is reported available (~0.6s). But executeCommand then waits for the shell's OSC 633 prompt-ready markers before writing the command. On my setup those markers arrive ~5s after the prompt is already accepting raw keystrokes — so:

  • I can type into the terminal immediately, but
  • the injected claude only lands at +5–6s, appended after anything I typed (the keystroke-append issue, cf #18779).

My ~/.zshrc sources in 0.13s (time zsh -i -c exit), so this is the first interactive prompt / shell-integration handshake, not rc cost.

Extension log (Terminal Mode, macOS, v2.1.158)

Creating new Claude terminal
Terminal shell integration available      (+0.6s)   <- executeCommand("claude") called here
New WS connection from: /                 (+5.5s)   <- claude finally launched & connected

Workaround (confirmed −2s)

Set "terminal.integrated.shellIntegration.enabled": false. The executeCommand path is skipped, the extension falls back to its hard-coded 3000ms sendText path, and launch drops from ~5.5s to a stable ~3.4s (3/3 runs). The log no longer shows "Terminal shell integration available".

Confirmed NOT related to MCP servers or session weight: disabling MCP (ENABLE_CLAUDEAI_MCP_SERVERS=false) cut ~3s off a plain-terminal claude -p but zero off the Ctrl+Esc gap.

Requests

  1. Don't block command injection on shell-integration prompt-ready indefinitely — use a short cap, then fall back to sendText.
  2. Make the 3000ms fallback timeout shorter / configurable.
  3. Clear/replace the terminal input line before injecting, so user keystrokes during startup aren't prepended to claude (fixes the !!!claude artifact, related #18779).

Env

  • Claude Code 2.1.158, macOS (darwin-arm64), Anthropic API
  • claudeCode.useTerminal: true, shell: zsh

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING