You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bumps every version source to 0.3.1. This is a patch release that restores a
working shell on Windows — the change is one hosts can feel, and on Windows it
is the difference between a usable agent and a dead one.
Why this release exists
v0.3.0 made the process boundary the default bash tool (bash tool v2, P6) with no platform gate on the dialect. On Windows the v2 executor spawns the bare
name bash, which is not there: every command — down to echo ok — returned [WinError 2] 系统找不到指定的文件。 Any session that needed a shell (for
example the CLI browser-harness) was dead on arrival. The previous executor had
always run cmd.exe there (via COMSPEC), so this was not "Windows was always
broken": v0.3.0 replaced a shell that exists with one that does not.
What changed
Windows now mounts pwsh; POSIX keeps bash. Exactly one shell tool is
registered, so "mounted as one dialect, running another" is unrepresentable.
Ported from the blueprint's peer family, not invented: argv [pwsh, -NoLogo, -NoProfile, -NonInteractive, -Command, ENCODING_PREAMBLE+command]
with the command as one argv element; env overrides with no TERM
(a POSIX concept); a four-rung resolution chain ending at the Windows
PowerShell 5.1 fallback that every Windows host has.
The system prompt renders the name of the tool the daemon actually registered, so it can no longer advertise a dialect the platform lacks.
The GUI registers a Windows session's pwsh output as an artifact again
(resultPanel.ts had a toolName === "bash" special case).
Rollback, one line:bash_tool_v2 = false under [sandbox], or EMRG_BASH_TOOL_V2=0 for a single launch. That path runs the previous executor,
which uses cmd.exe on Windows — which is why P8 had to land before the old
tool is deleted.
Honest limits
The new tests spawn no shell, and this cycle had no Windows hardware. The
Windows-side acceptance items are marked "ported, NOT verified" in the code:
a real echo ok / $PSVersionTable.PSVersion returning exit 0, the 5.1-only
machine taking the fallback, the tool table showing pwsh and not bash, and the
two restricted-token contracts (ConstrainedLanguage under read-only; named-pipe
EPERM under either confined mode). The resolution chain, argv shape, env set and
platform gate are pinned by tests plus five mutation arms, all killed.
Merged under the host's direct release directive (2026-09-23T18:06 「优先处理rant…完成后发布新版本」, after the P8 rant was completed by #1548 landing as b92ed00d), so I am stating where this departs from the standing rule rather than letting it pass silently.
Departure: check-vote-count reports 0/3 valid votes. This instance pushed the head (f450075b), so it must abstain on its own head — the PR cannot reach 3 votes without cycles that would be reviewing a tree it could have voted on itself. The same authority path carried #1546 (v0.3.0), and, as there, the merge rests on measurement instead of on votes:
check-pr-base: base is master.
check-merge-freshness: FRESH — master is an ancestor (behind_by=0) and the passing run's merge base b92ed00dis master's tip.
Landing tree measured, not assumed: landing tree a2e663491d201caf80a6dc8c12c3934c948472c2 == the head's tree, byte for byte; check-merge-landing-diff lists 8 changed paths and every one of them is landed; no path reads backwards.
check-merge-plan-suite: HEALTHY, suite 5152 passed / 30 skipped on the final tree.
CI run 35847739428 on f450075b: test ✅ and test-windows ✅ — the Windows leg is the one that matters here, since the defect this release fixes is invisible on ubuntu.
Merge state MERGEABLE/CLEAN.
The reason the release is urgent rather than routine: v0.3.0 is the version a Windows host already has, and it ships the bare-name bash spawn with no platform gate, so every shell command there fails with [WinError 2]. Until this tag is published, the working state on Windows is the one-line rollback [sandbox] bash_tool_v2 = false (read at startup, so the daemon must be restarted) or EMRG_BASH_TOOL_V2=0 for a single launch.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Release v0.3.1
Bumps every version source to 0.3.1. This is a patch release that restores a
working shell on Windows — the change is one hosts can feel, and on Windows it
is the difference between a usable agent and a dead one.
Why this release exists
v0.3.0 made the process boundary the default
bashtool (bash tool v2, P6) withno platform gate on the dialect. On Windows the v2 executor spawns the bare
name
bash, which is not there: every command — down toecho ok— returned[WinError 2] 系统找不到指定的文件。Any session that needed a shell (forexample the CLI
browser-harness) was dead on arrival. The previous executor hadalways run
cmd.exethere (viaCOMSPEC), so this was not "Windows was alwaysbroken": v0.3.0 replaced a shell that exists with one that does not.
What changed
pwsh; POSIX keepsbash. Exactly one shell tool isregistered, so "mounted as one dialect, running another" is unrepresentable.
[pwsh, -NoLogo, -NoProfile, -NonInteractive, -Command, ENCODING_PREAMBLE+command]with the command as one argv element; env overrides with no
TERM(a POSIX concept); a four-rung resolution chain ending at the Windows
PowerShell 5.1 fallback that every Windows host has.
registered, so it can no longer advertise a dialect the platform lacks.
pwshoutput as an artifact again(
resultPanel.tshad atoolName === "bash"special case).bash_tool_v2 = falseunder[sandbox], orEMRG_BASH_TOOL_V2=0for a single launch. That path runs the previous executor,which uses
cmd.exeon Windows — which is why P8 had to land before the oldtool is deleted.
Honest limits
The new tests spawn no shell, and this cycle had no Windows hardware. The
Windows-side acceptance items are marked "ported, NOT verified" in the code:
a real
echo ok/$PSVersionTable.PSVersionreturning exit 0, the 5.1-onlymachine taking the fallback, the tool table showing
pwshand notbash, and thetwo restricted-token contracts (ConstrainedLanguage under read-only; named-pipe
EPERM under either confined mode). The resolution chain, argv shape, env set and
platform gate are pinned by tests plus five mutation arms, all killed.
Source: #1548 (merged as
b92ed00d); P1/P3/P4/P6 in #1540, #1541, #1542, #1545.