Terminal Usage Fails with "VSCE output start escape sequence" Error

[libertyteeth]

Which version of the app are you using?

3.10.5

Which API Provider are you using?

Anthropic

Which Model are you using?

Claude 3.7 Sonnet

What happened?

Every time Roo Code invokes the terminal, it fails to read the output. Instead, it gives an error about "VSCE output start escape sequence", followed by a suggestion that it might be an "Upstream VSCE Bug?", and asks the user to use a supported shell. I am already using a supported shell, so this didn't make sense.

A big clue from "lateral testing" was that Cline didn't have this issue.

So I spent some time and tokens having AIs analyze the codebase.

The fix, from local testing: remove the sleep of 0.050 seconds (oddly significant!). :) This is in src/integrations/terminal/TerminalRegistry.ts; the line to comment out is (indented in the code):

PROMPT_COMMAND: "sleep 0.050",

The error message, which originates from Roo Code itself, was misleading -- pointing to an upstream issue when the fix was local.

(Also note, this issue persists across all models and API providers I tested, not just Anthropic's Claude 3.7 Sonnet.)

Steps to reproduce

1. Use any model and API provider.
2. Prompt: "Please run 'ls', we're testing if the terminal works."
3. Observe the AI attempt to run ls, and fail with the "VSCE output start escape sequence" error.

Expected Behavior

The terminal command (ls or any other) should execute successfully without errors, as it does in Cline.

Actual Behavior

Roo Code throws the "VSCE output start escape sequence" error and fails to execute the command.

Proposed Fix

Remove the sleep 0.050 delay in the terminal-handling code. This resolves the issue in my testing.

Relevant API REQUEST output

Additional context

This Roo Code instance was running on Arch Linux, in Code OSS version 1.96.4. I have not tested any other platform. I realize that the sleep may have been needed on other platforms. Or, prior to the bug being fixed in VSCE? I saw this in my wandering:

microsoft/vscode#237208

The clue that brought me to this point, today, was: I was thinking, "What is different from my environment, that might impact a terminal?" I had a custom prompt. Having the AI investigate in that direction helped narrow it down.

Thank you so much for providing this wonderful tool!

[cte]

CC @KJ7LNW

[cte]

@libertyteeth - Thanks for digging in; there's quite a storied history behind that sleep.

[KJ7LNW]

@libertyteeth, good sleuthing!

That delay was added after several weeks of troubleshooting and back and forth with VSCE developers working on shell integration. The bug that you referenced is one such discussion, and there were others.

It is interesting that now turning off the delay solves a problem! I would love to remove that line and discontinue the workaround, perhaps that it is no longer necessary.

However, there is a risk that it will introduce regressions in other users. I am hoping I can reproduce the problem exactly and come up with a solution that will still work for everyone else.

Please answer the following questions, so I can get a better picture of what is going on:

1. you mentioned that you have a custom prompt:

• if you disable your custom prompt does Roo work properly? (I realize you probably want your custom prompt, and we can work in that direction, but answering this question will help me with troubleshooting)
• how is your custom prompt configured?
• is it yours, or a common custom third party prompt that is available to source into your profile (like powerlevel10k)?

2. what shell are you using (bash zsh ps1 other)
3. which operating system
4. exactly which version of vscode (help->about->copy) are you running?

[libertyteeth]

Thank you! (I once spent two weeks tracing an FDDI driver bug for Harris, which turned out to be fixed with "zero lines changed" ("0 LOC") -- one line added and one line removed. Metrics of old were sometimes amusing!) :)

Here are my answers; please let me know if I can further clarify anything!

1. When I comment out the ". ~/bin/custom-prompt.sh" line in my .bashrc, it reverts to a different prompt but that one still causes the error. So I added to the end of .bashrc:

# Make the prompt simple
export PS1='$'

Then started a new terminal, then "code" from there, and had it run 'ls', and still got the error.

So it seems on my system it is not the prompt that is causing it; that was both a red herring (my thought that it was the difference), AS WELL AS a clue -- since that's what the codebase is actually manipulating! That's like divine guidance, that's weird. Anyway, it must be something else.

I have an Ubuntu system and tested it there; with or without the custom prompt, it was working fine. So it makes sense that few reported this.

2. I'm using bash, via the "Terminator" application in Arch Linux, with Gnome as the desktop.

3. Arch Linux.

4. Copied below:

Version: 1.96.4
Commit: cd4ee3b1c348a13bafd8f9ad8060705f6d4b9cba
Date: 2025-01-17T08:53:36.849Z
Electron: 32.2.8
ElectronBuildId: undefined
Chromium: 128.0.6613.186
Node.js: 20.18.1
V8: 12.8.374.38-electron.0
OS: Linux x64 6.13.1-arch1-1

---

I could write a PR, making a UI config option "Fix for 'VSCE output start escape sequence' error" (or similar text), but since that VSC fix is due to come out soon it might eliminate the need for the workaround that stopped my configuration from seeing the terminal output. Right now I will run on my "version 9.0.0" (high enough that a new release should not trigger an auto-update, so I don't have to touch any other settings :) ), as the bug I referenced indicated that 'tomorrow' (the 27th) might be the release with the fix.

My thoughts there being: if the release is imminent, then there may be no need to add a UI element if it's only needed for a day (or two or three, depending on how long it takes the pipeline to trickle the fix to my platform).

Let me know your thoughts?

Thank you!

[KJ7LNW]

It would be great if they released that tomorrow, I would love to see all of upstream terminal fixes in the official VS Code really, so I no longer have to tell people to use an insider's build. There really is no reason that a 50ms delay should prevent and start sequence, especially since the prompt happens after the command complete and not before it starts.... so it is very curious that commenting out PROMPT_COMMAND has any effect at all.

Version: 1.96.4

I think at least part of the fix that you referenced in microsoft/vscode#237208 has been released in 1.98.x.

Can you try a newer version and see if that helps?

[rilez]

FWIW, I had the same issue (3.10.5, WIndows/Powershell 7.4.7). The suggested sleep fix didn't have any effect, but removing the customizations in my pwsh profile resolved it. Happy to provide more info if needed (I suspect it's re: oh-my-posh).

I also had to apply the tips from this Perplexity post that's been shared in the Discord
https://www.perplexity.ai/search/in-vs-code-on-windows-i-m-gett-zbGXKOOCSJuIg8d6hGl5GA

[KJ7LNW]

Happy to provide more info if needed (I suspect it's re: oh-my-posh).

@rilez have you tried enabling shell integration in OMP? Both VSCode and Roo support \x1b]133;X escape sequences, although I have not actually tested with OMP myself:

[ https://ohmyposh.dev/docs/configuration/general ]

[hannesrudolph]

@KJ7LNW What should the status of this issue be set to?

[mford7998a]

im having this same issue using windows 11 and the standard powershell. it just started happening one day and ive yet to be able to fix it.

im gonna try what rilez mentioned and will report back if that works.

any other tips would appreciated.

also, my python installation is somehow not working when i try to run python scripts in vscode, it opens the windows dialogue asking me what program i want to use to run "python" with, and it never had this issue for the last two years. dont know if this is related or not, but both seem to have started at the same time

[KJ7LNW]

When you say that you are having the same issue , do you mean that you successfully commented the sleep, and it works in Windows? that seems unlikely because that environment variable is not used by Windows I do not believe ...