Change:
handleContinuationEnd(): void; handleRightPromptStart(): void; handleRightPromptEnd(): void; <del> handleCommandStart(): void; </del> <ins> handleCommandStart(options?: IHandleCommandStartOptions): void; </ins> handleCommandExecuted(): void; handleCommandFinished(exitCode: number | undefined): void; /**

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.66 OS Version: ArchLinux Shell integration doesn't work with oh-my-zsh and powerlevel10k. The indicator is only shown for the first line and the disappear. Another problem is the warning from powerlevel10k about instant prompt (see attached screenshot) Steps to Reproduce: zsh oh-my-zsh and powerlevel10k theme vscode and start new zsh terminal to run some commands Screenshot: !
Having the same issue.
Refs Out of curiosity, P10K explicitly disables the integration (as it does not work anyway and yet makes the prompt slower). So, if someone tries to debug this situation, make sure to comment out the following line before testing: P10k is extensively used (has almost 30k stars), so it would be very nice if VS Code can manage to make the Shell Integration work with it.
We'd like to support it, the summary of the discussion/situation around this was: We're using custom sequences to control everything and extend the shell integration. Since we launch the process we can guarantee we're in VS Code (except for edge cases). VS Code's shell integration will eventually be enabled by default, it works by wrapping your PS1, PROMPTCOMMAND and eventually . In order to have the most impact, we aim to support most_ shells so more users get it by default, with a manual setup option for complex shells and sub shells. This will come in the form of essentially running the script manually in your rc file and disabling the automatic injection.

Powerlevel10k is complex, it handles shell integration used by other terminals manually. I don't blame for not being keen on our solution if it means he needs to implement a VS Code-specific solution. After a bunch of back and forth I recommended we all take a step back, disable it explicitly for now and let us stabilize more so we don't rush into something we will regret. We will probably at some point document the sequences (it's still getting stabilized and subject to change) or maybe support the more common sequences which would let it just work without additional changes. My main concern with supporting multiple shell integration protocols is them conflicting with each other, but that's probably the right thing to do and we could have a switch which disables the other protocol.
Haven't tested this much but this seems promising after some trivial changes: ! Not sure yet why we're not getting the cwd sequence, I'm forcing shell integration on via
Another problem is there doesn't seem to be a nice way to extract right prompt or continuations so this ends up happening: <img width="486" alt="Screen Shot 2022-06-10 at 1 41 39 pm" src="https://user-"We could make some guesses by examining the content of the cells but that's not ideal. It would be a shame if we lost the fairly reliable extraction of the command since a lot of the interesting future functionality will be built on that like extension APIs and autocomplete.
In general in zsh it's impossible to extract the command from the data written to the terminal. The command isn't always visible. For example, try entering a command that's taller than the height of the terminal (use ESC Enter or Alt-Enter to insert a line break). Or try running and entering a command that's longer than the width of the terminal. If a terminal needs to know the command being executed, it'll have to provide an extension so that zsh can supply the command explicitly.
I'm willing to implement a VS Code-specific solution but I would need you to provide a spec of VS Code terminal extensions and promise backward compatibility.
The feature that exposes the commands is not particularly discoverable but it works pretty great for the general case in all shells at the moment, I know there are edge cases when it will fall apart though.

For pwsh the column and line are not reliable because of conpty so we do pass through the command line there and it works well: ! Great, I wouldn't want you to without us committing to it . We're still not at the stage where reliability will become more important so we're just passively thinking about this problem atm. I'll let you know if we'd like you to do that. For now we can just disable the parts that need the command which will still give us the markers/command navigation. I have a couple of questions that would save me a bunch of time if you know: I see the window icon/title is coming through in and , is there a trick to getting the cwd to be sent via something like , or ? Is the right way to test against?
Sounds good. Powerlevel10k doesn't set terminal title and doesn't report the current directory. These things aren't related to prompt and can be done separately. Powerlevel10k provides only prompt. The best way is to set . No need to export it. is normally set by the native integration of iTerm2. It doesn't work with Powerlevel10k, so Powerlevel10k undoes that and enables its own integration.
I put a PR out which should make the upcoming release With it, shell integration should work with powerlevel10k if it emits the more common standard OSC 133 A, B, C, D sequences. This won't give all the features but it will turn on command decorations with exit status, command navigation (ctrl/cmd+up/down) and the overview ruler. if you could emit the OSC sequences for VS Code that would be great, checking $TERM_PROGRAM = vscode should be a reliable way of doing that. I'll let you know if we end up committing and documenting the sequences we use, in which case a command line sequence could light up more features.
Awesome! Have you tried it? Powerlevel10k emits OSC 133 if you set . It's a good idea to verify that it works with , too. Powerlevel10k emits OSC 133 if users explicitly request it with , or if they activate the built-in shell integration in their terminals. Powerlevel10k detects the latter, undoes the damage if necessary, and turns on its own OSC 133 implementation.

Currently this is implemented for iTerm2 and Kitty and I could implement the same logic for vscode: If is set when powerlevel10k is sourced, unset it and enable OSC 133. Does this sound reasonable?
I installed the stable build of powerlevel10k and never seems to work, turns on OSC 133 though. when the one is set works fine. That's perfect . We have started using that variable to prevent recursing or calling the scripts multiple times, ie. so it works when it's injected by VS Code and installed manually: