Polyglot Notebook VS Code: Notebooks outputting .NET objects instead of PowerShell

[MrMKJ]

Describe the bug

When working with variable containing PowerShell objects or object collections the cell output is make up of .NET style objects rather than PowerShell CLI output. This also often contains errors that are not consistent with the same commands run in the VS Code terminal.

This has started happening on all my devices, both personal and work/corporate managed.

Please complete the following:

• OS
  • [x] Windows 11 (4 different machines, both x64 and Arm64 versions)
• Browser
  • [x] Edge
• Frontend
  • [x] Visual Studio Code

Screenshots

[MrMKJ]

This issue was previously raised in the VS Code repo but has been closed as an extension related issue not a VS Code bug.

https://github.com/microsoft/vscode/issues/257266

[erhardeibl]

For context, I want to extend on a few points made in original issue thread before it was closed: This issue occurs with many commands including git clone, docker build, helm release etc. Notebooks of reasonable complexity produce thousands of these objects, rendering themselves practically unusable.

[jul-m]

I see the same behavior with docker buildx build command. It appears PowerShell treats the output of some commands as stderr rather than stdout. This is not specific to commands run from a notebook: running the same command in a regular pwsh terminal also produces output on stderr (but since the output color does not change to red, we cannot see it without trying to capture the output).

As a temporary workaround, I redirect stderr to stdout for the affected commands:

<my_command> 2>&1 | Out-String -Stream | Write-Host

This forces stderr to be redirected to stdout, captures the full string, and displays it cleanly.

[jonsequitur]

This behavior was introduced by #3912, the intent of which was to align PowerShell outputs more closely to C# outputs. I think this deserves a discussion about how to accommodate both of these scenarios.

[alexandair]

@jonsequitur I would really like to know who thought it was a good idea to ignore, for example, Format-Table command, and output .NET object.

Default output for PowerShell cells makes notebooks unusable without additional tweaks.

[sassdawe]

Default output for PowerShell cells makes notebooks unusable without additional tweaks.

+3000!

I basically had to version-pin the extension to avoid getting these bits because we are scripters and not C# developers.

[ninmonkey]

Summary

As a work around, add | Out-Default to the end of your commands

Fixing objects

Try appending Out-Default to the end of your commands. That seems to force the expected behavior

Get-Process Code | Select-Object -First 1
Get-Location | Ft -Auto *

# Becomes
Get-Process Code | Select-Object -First 1 | Out-Default
Get-Location | Ft -Auto * | Out-Default

Fixing Stderr

Redirection from above worked. I was also able to get different output using PSNativeCommandUseErrorActionPreference

pushd 'g:\temp'
# I think it's scoped, but I wrapped it to be safe
& { 
    try {
        $PSNativeCommandUseErrorActionPreference = $true
        $ErrorActionPreference = 'stop'
        $res = git log
    } catch {
        $_ | fl * -force | Out-Default
        throw
    } finally {
        $ErrorActionPreference = 'continue'
    }
}

[FH-Inway]

This broke several tutorial notebooks I've written for PowerShell modules. It seems reasonable to expect that notebooks produce output equal or similar to the output when running the same language commands in their native environment.

From what I understand from the pr that introduced this change, this seems to be the main point:

Rich .NET objects (like DataFrame) are published as objects, enabling proper rendering using registered formatters.

It seems to me that in case there are no registered formatters, this results in the unexpected output. If that is the case, the proposal is to fall back to the previous behavior if there are no registered formatters.

The following Gist provides a simple example that shows the regression in output behavior: https://gist.github.com/FH-Inway/4279a5e487b4cb80ed04a3270464482f

[FH-Inway]

@jonsequitur I started work on my proposed solution in https://github.com/FH-Inway/interactive/pull/2. As I'm new to the internals of the extension and dotnet-interactive, I cannot fully evaluate the implementation GitHub Copilot has written. From what I can evaluate, it seems to be in the right direction. Let me know if you are open to receive this pr.

[SQLDBAWithABeard]

Be awesome if this was fixed, please, thank you

[gaelcolas]

This behavior was introduced by #3912, the intent of which was to align PowerShell outputs more closely to C# outputs. I think this deserves a discussion about how to accommodate both of these scenarios.

I feel that enabling this behaviour to support specific rendering using registered formatters should be opt-in at both cell or document level.

I understand the desire to leverage formatter, but when we use notebooks to demonstrate how commands behave in PowerShell, such as how-to guide, this change makes simple notebooks useless as it confuses the end-users/readers.

This should be considered a regression, and was definitely a breaking change for many of us PowerShell users. Is it possible to have a quick opt-in/opt-out document-level configuration @jonsequitur ?

[FH-Inway]

@jonsequitur Thanks for the merge of #4100 . Any idea when we can expect a release with that change?

[jonsequitur]

@FH-Inway The pre-release version of Polyglot Notebooks has been released which should contain this change (as well as the update to .NET 10). Please give a try.

[FH-Inway]

@jonsequitur I tried to install the pre-release version of Polyglot Notebooks, but there seems to be no new version available after 1.0.6323011 released on June 24th 2025. Not sure why, on the extension page it says the following, so something changed yesterday.

Version | 1.0.6323011 Released on | 16.5.2020, 00:37:58 Last updated | 10.12.2025, 18:35:25

[jonsequitur]

Sorry about that. We're seeing a problem in our publishing pipeline. I'll report back when it's resolved.