Skip to content

Powershell ShellId falls through to "Microsoft.PowerShell", resulting in default profile loading #2842

Open

Description

@no-identd

I'll say beforehand:

This issue text sucks and is a disorganised mess, and that's on me. It's due to a lack of time, and a lot of fatigue on my end. Most of it, frankly, caused by incomplete glue by Microsoft. I'd hoped vscode 141 along with PSES 1.1 in the September preview update would finally absolve me of the pain by enabling sane sandboxing for powershell, and it mostly did, but as soon as I figured out most of the missing parts (like deny listing user temp and whitelisting the user modules folders), I run into this, and it drives me up the wall. Sadly most of the context I could supply for this sits behind corporate bureaucratic hurdles I lack the energy for crossing, which also prevents me from reproducing all of this in my spare time, otherwise I'd supply a saner story around this.

Anyway, having said that, this gap indirectly introduces tons of user experience regressions downstream in vscode. Most of which not reported yet, but it's only a matter of time. I figured I'd raise this directly upstream since this doesn't seem like it originates in VSCode and doesn't belong in MXC either, albeit I could have that last part wrong.

Related issues, more or less:

microsoft/vscode#313790

microsoft/vscode#334029

microsoft/vscode#338882 (which IMHO shouldn't have gotten closed and rests on some sort of misunderstanding/miscommunication)

microsoft/vscode#334029

#1911

The most basic regression and vague resemblance of a user story I can supply for this:

Nobody wants their whole hueg powershell profile loaded for every tool call. That takes a while and it adds up. And having a heavily customized PSReadline makes this worse. But at the moment that's exactly what happens. Ofc one can attach themselves to some env var as a proxy for "do we run inside agent host", but…

@SeeminglyScience sorry for the random tag, but I suspect you'll grok what I'm trying to get at here and in case you could spare the time may I ask whether you might translate my gobbledygook double Durch gibberish ramble to something actually sane and more actionable by devs? I'd suspect this issue will otherwise get closed and in a couple of weeks to months reappear raised by someone else. The agent SDK's shell if it uses powershell should, just like VSCode, have the ability to haver its own profile. And right now it can't. :/

Cc @anthonykim1 @connor4312

Activity

  1. Bobdedoxrx commented on Oct 15, 2026

    @Bobdedoxrx

    I'll say beforehand:

    This issue text sucks and is a disorganised mess, and that's on me. It's due to a lack of time, and a lot of fatigue on my end. Most of it, frankly, caused by incomplete glue by Microsoft. I'd hoped vscode 141 along with PSES 1.1 in the September preview update would finally absolve me of the pain by enabling sane sandboxing for powershell, and it mostly did, but as soon as I figured out most of the missing parts (like deny listing user temp and whitelisting the user modules folders), I run into this, and it drives me up the wall. Sadly most of the context I could supply for this sits behind corporate bureaucratic hurdles I lack the energy for crossing, which also prevents me from reproducing all of this in my spare time, otherwise I'd supply a saner story around this.

    Anyway, having said that, this gap indirectly introduces tons of user experience regressions downstream in vscode. Most of which not reported yet, but it's only a matter of time. I figured I'd raise this directly upstream since this doesn't seem like it originates in VSCode and doesn't belong in MXC either, albeit I could have that last part wrong.

    Related issues, more or less:

    microsoft/vscode#313790

    microsoft/vscode#334029

    microsoft/vscode#338882 (which IMHO shouldn't have gotten closed and rests on some sort of misunderstanding/miscommunication)

    microsoft/vscode#334029

    #1911

    The most basic regression and vague resemblance of a user story I can supply for this:

    Nobody wants their whole hueg powershell profile loaded for every tool call. That takes a while and it adds up. And having a heavily customized PSReadline makes this worse. But at the moment that's exactly what happens. Ofc one can attach themselves to some env var as a proxy for "do we run inside agent host", but…

    @SeeminglyScience sorry for the random tag, but I suspect you'll grok what I'm trying to get at here and in case you could spare the time may I ask whether you might translate my gobbledygook double Durch gibberish ramble to something actually sane and more actionable by devs? I'd suspect this issue will otherwise get closed and in a couple of weeks to months reappear raised by someone else. The agent SDK's shell if it uses powershell should, just like VSCode, have the ability to haver its own profile. And right now it can't. :/

    Cc @anthonykim1 @connor4312

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions