Prompt too long

Status Open
Reported on v2.1.250
Maintainer reply None cached
Activity 0 comments · opened Aug 28, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Bug Report: Claude Code for VS Code
Environment
Extension: Claude Code for VS Code (Anthropic), identifier anthropic.claude-code, version 2.1.250
Claude Code CLI: version 2.1.250 (Claude Code) once properly installed
OS: Windows, PowerShell (native Windows install, not WSL)
Project location: a project folder synced via OneDrive (...\OneDrive\Documents\<project>)
Model: claude-sonnet-5
Bug 1: Native Windows installer does not add Claude Code to PATH

Install command used (official, from https://code.claude.com/docs/en/setup):

powershell
irm https://claude.ai/install.ps1 | iex

Expected: After running the installer, claude should be runnable from any new terminal.

Actual: The installer completed and correctly placed files under %USERPROFILE%\.local\share\claude\versions\, and the binary itself worked fine when invoked directly:

powershell
& "$env:USERPROFILE\.local\bin\claude.exe" --version

→ 2.1.250 (Claude Code)

...but %USERPROFILE%\.local\bin was never added to the User Path environment variable. This was confirmed directly:

powershell
[System.Environment]::GetEnvironmentVariable("Path","User")

→ .local\bin was NOT present in the output

This persisted even after a full OS restart (not just closing/reopening the terminal or VS Code) — ruling out a simple environment-variable-caching explanation. The only fix was manually appending it:

powershell
[System.Environment]::SetEnvironmentVariable("Path", $env:Path + ";$env:USERPROFILE\.local\bin", "User")

After that, claude --version and a full claude session worked normally from any new terminal.

Impact: Anyone using the documented native Windows installer may be left with a "successfully installed" CLI that is completely unusable from the command line, with no error message pointing at PATH as the cause — the only symptom is claude : The term 'claude' is not recognized....

Bug 2: VS Code panel fails with "Prompt is too long" on trivial prompts, independent of actual context usage

Steps to reproduce:

Open the Claude Code panel in VS Code (extension v2.1.250) in a project.
Start a new, low-usage session (confirmed via the Context Usage panel — as low as ~45.3k / 1.0M tokens, i.e. 5% used).
Send a trivial message, e.g. hi, with no file attachments.

Expected: A normal response, same as sending hi via the standalone CLI (which works instantly and correctly).

Actual: Immediate Prompt is too long error, every time, even though:

The Context Usage panel shows only ~5% utilization at the moment of failure (Messages: ~15k tokens; System prompt, System tools, Memory files, Skills all normal/small).
The same exact text sent through the standalone claude CLI (same account, same machine, once Bug 1 above was fixed) responds correctly and instantly.

What was ruled out while troubleshooting:

Long/bloated conversation history — reproduced in a brand-new session with healthy context usage, not just a long-running one. (Separately, an earlier, unrelated instance of this error in a different, very long-lived session did correlate with a session-history bug — that session's Messages had ballooned to 5.6M / 1.0M tokens (560%) with the autocompact buffer never engaging. That appears to be a distinct issue from the one described here, since this report's repro happens on a freshly-started, low-usage session.)
File attachments — reproduced with zero attachments.
Project-level misconfiguration — inspected the project's .claude/settings.local.json and .claude/commands/; found only permission allowlist entries and one manually-invoked slash command, nothing that auto-loads content or runs on every prompt. No CLAUDE.md, no hooks.
Outdated extension — extension was already on the latest version (2.1.250, released ~14 hours prior); updating (it auto-updated during troubleshooting) did not resolve it.
New vs. legacy panel UI — toggling the "Claude Code: Use Terminal" setting (which switches the panel to run through an actual terminal-based claude process instead of the newer embedded interface) did not resolve it, tested both before and after fixing Bug 1 above.
CLI/account/network issues — the standalone CLI, using the same logged-in account, on the same machine, works perfectly and instantly for the same prompt. This isolates the bug specifically to the VS Code panel/extension itself.

Impact: The Claude Code VS Code panel is completely unusable for this project/session — every message fails instantly — while the underlying Claude Code program works correctly. This makes the panel appear totally broken to the user despite the account, model access, and CLI all functioning normally.

Suggested next steps for investigation
Check what the VS Code extension sends as the actual request payload when this error fires — my suspicion is it's including something not reflected in the Context Usage panel's numbers (possibly related to the "Remote Control" feature shown active in the panel, or some other panel-side augmentation of the request that the CLI path doesn't add).
Reproduce with a project of similar size/shape (large folder — many binary assets, a few very large text/markdown/JSON files at the project root) to see if the panel's workspace-awareness features behave differently than the CLI's when a large folder is open, even without those files being explicitly referenced in a prompt.

What Should Happen?

See first box

Error Messages/Logs

See first box

Steps to Reproduce

See first box

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.250

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_

View original on GitHub ↗