[Bug]: Bash still faulty

[LMunro1]

Platform

Windows

Wayland Version

v011.18

Bug Description

Wayland Doctor shows 10 passes and 1 workspace warning, which is an admin job I will see to. However, the Bash tool still appears faulty: running cmd /c echo BASH_STDOUT_TEST && cmd /c ver returns exit code 1 with empty STDOUT and empty STDERR. This seems to be a Bash output/session issue that is not being resolved ... for me anyway.. not sure what to do if anything

Steps to Reproduce

every question and check being done to see if working yet

Expected Behavior

whatever Bash does ... it is not doing.. the bot has been toi check several times obver this las t week

Actual Behavior

returns exit code 1 with empty STDOUT and empty STDERR.

Additional Context

just put in what the bot found as I have no idea

[LMunro1]

What's actually happening with Bash here
The Bash tool I have access to is Wayland's own sandboxed shell. When I call it, Wayland runs the command in a restricted environment and passes me back the output.

The problem is that this sandboxed environment isn't returning output — not even for a basic echo command. That's a Wayland sandbox issue,

[FerroxLabs]

Thanks — and the detail that Doctor passes 10/11 while Bash still fails is the useful part, because it rules out the obvious environment causes and points at the Bash execution path specifically.

Taking this into the core lane. What I can say precisely, without overclaiming:

This matches a defect we already track, not a new unknown: Windows Bash losing child output. Related: #552 (bash output capture broken). Two production root causes were identified for the Windows path in earlier analysis — verbatim \\?\ path canonicalization, and cmd quote-mangling. Your repro is a nested cmd invocation (cmd /c echo … && cmd /c ver run through a shell that is itself cmd /C), which is exactly the shape where the quoting defect bites: the outer cmd /C re-parses the string, and the && and inner quotes do not survive intact. That is consistent with exit 1 plus empty stdout AND empty stderr — the child never runs as intended, and nothing is captured to report.

Corroborating signal from today: on our Windows CI leg, tool_formatter_real_payloads::bash_stderr_is_surfaced failed with sandbox child execution failed (it passed on re-run, so it is intermittent there rather than constant). Same area, still not solid.

What I have NOT verified: whether this still reproduces on current Core. You are on v0.11.18; Core is now 0.12.26, and the Windows execution path has changed substantially since. I am not going to tell you it is fixed, because I have not run your command on 0.12.26 on Windows.

Next step is ours, not yours — we have a Windows box and will run your exact command against 0.12.26 and report the result here. If you want to check independently in the meantime, wayland-core --version will confirm which engine your Desktop is actually driving; the two version independently.

No action needed from you. Sorry it has been a week of this.

[FerroxLabs]

Measured on 0.12.26 — your command works. Details so you can check my working.

I said we'd run it rather than ask you to. Here is exactly what was run and what came back.

Setup — deliberately the shipped artifact, not a dev build, because that is what you actually receive:

host	real Windows 11, build 10.0.26200 (physical machine, not CI)
install	npm install @ferroxlabs/wayland-core@next → resolved 0.12.26-rc.2
driver	wayland-core sandbox exec '<command>'

sandbox exec is the honest probe here: its own help says it runs the command "through the agent's shell tool, so the containment applied is the containment the agent applies" — the real Bash path, no provider or API key involved.

Your exact command:

> wayland-core sandbox exec 'cmd /c echo BASH_STDOUT_TEST && cmd /c ver'
Exit code: 0
STDOUT:
BASH_STDOUT_TEST

Microsoft Windows [Version 10.0.26200.8875]

STDERR:

Exit 0, both lines present, both halves of the && ran. The failure you hit — exit 1 with empty STDOUT and empty STDERR — does not occur on 0.12.26.

Controls run alongside so this isn't a "everything looks fine" answer: echo HELLO_CONTROL and echo FIRST && echo SECOND both clean.

One real thing I did find, so it's on the record

A nested cmd /c gains one spurious trailing double-quote in its output:

cmd /c echo NESTED      ->  NESTED"
cmd /c echo TWO WORDS   ->  TWO WORDS"
echo NOQUOTE            ->  NOQUOTE        (clean)

That is the residual half of the quote-handling defect behind your report. On 0.12.26 its effect is output corruption, not execution failure — right exit code, command actually runs, one character wrong. Tracking it separately for 0.12.27.

Why I'm leaving this issue open

You are on Desktop v0.11.18, which bundles its own Core. I have shown Core 0.12.26 is good; I have not shown that your Desktop is using it. Whether/when Desktop picks up the newer engine is a Desktop-side question.

So: please reopen the conversation here once your Desktop updates, and if it still misbehaves we will chase the Desktop bundling path instead. I'd rather leave this open and be wrong about it being fixed for you than close it and have you hit it again next week.