Bash tool never executes on Windows — sandbox drops the environment, then hangs to a timeout instead of failing fast

[jonlwheat2-gif]

Note: FerroxLabs/wayland's .github/ISSUE_TEMPLATE and CONTRIBUTING.md do not specify a required bug-report format (CONTRIBUTING.md covers CLA/ground rules only, no template). This report uses standard OSS bug-report structure instead, and is fact-checked directly against the official docs at docs.getwayland.com/core/bash-isolation and docs.getwayland.com/core/sandbox.

Reproduced on two separate machines, two Windows versions (10 and 11), isolated to Wayland-Core specifically — no other tool or application on either machine is affected. The one documented workaround (WAYLAND_ALLOW_NO_SANDBOX=1) was tested and does not fix it.

Summary

On Windows, every call to the built-in Bash tool fails. Not with a clean error — it hangs and is eventually killed by a timeout, with the timeout duration inconsistent across consecutive attempts in the same session. Root cause, found in Wayland's own Settings UI: Security & Permissions → Env-Passthrough Allowlist is empty by default, so PATH (and everything else) is never forwarded to whatever process actually runs Bash commands. The host machine has node, npm, npx, and git all present, independently version-checked, and working outside of Wayland — this is not a "user is missing a dependency" issue, it's the sandbox boundary discarding the environment it needs to do anything. A second, independently reproduced candidate cause was also found and is detailed further down: this machine's PATH resolves bare bash to a stopped WSL distro's launcher stub before it reaches Git Bash, and invoking that stub is ~120x slower even outside any sandbox (7,127 ms vs. 60 ms, measured directly) — if the sandboxed Bash tool resolves bash by name instead of by the absolute path Wayland's own diagnostic already found, that alone could produce exactly the kind of open-ended hang observed. This candidate gained significant weight after further testing (see below): the documented WAYLAND_ALLOW_NO_SANDBOX=1 opt-out — which should bypass the OS-level AppContainerBackend sandbox entirely — was tested with a fully verified environment refresh and did not fix the hang at all. That means the AppContainerBackend sandbox layer itself is probably not where this is stuck; something upstream of the sandbox choice (env-passthrough, or command resolution hitting the WSL stub) is the more likely culprit.

Environment

Wayland (desktop app)	v0.11.18 (production)
Wayland-Core (wcore)	v0.12.25
OS	Windows 10.0.19045 x64 (win32) — confirmed via [System.Environment]::OSVersion
Electron	41.6.0
Chromium	146.0.7680.216
Node (Electron built-in, per Wayland)	v24.15.0
Node (actual system PATH, verified via node -v)	v22.23.1 — a different runtime than the Electron-bundled one, see note below
npm (verified via npm -v)	10.9.8
npx (verified via npx -v)	10.9.8
git (verified via git --version)	2.55.0.windows.3
bash (verified via bash --version)	GNU bash 5.3.15(1)-release (x86_64-pc-cygwin)
Detected shell	C:\Program Files\Git\usr\bin\bash.exe (Git Bash)
Model in session (not the cause — see Root Cause)	minimaxai/minimax-m3 via NVIDIA NIM
Log file	C:\Users\s3np4\AppData\Roaming\Wayland\logs\2026-07-15.log

Wayland's own startup diagnostic block is reproduced verbatim below (checked byte-for-byte against the log with hexdump, since the console rendering of this block is misleading — see the correction note after it):

[Wayland:env] ════════════════════════════════════════════════════
[Wayland:env]   Wayland v0.11.18 (production)
[Wayland:env]   OS       : win32 10.0.19045 (x64)
[Wayland:env]   node     : ?  (C:\Program Files\nodejs\node.exe)
[Wayland:env]   npm      : ?  (C:\Program Files\nodejs\npm)
[Wayland:env]   npx      : ?  (C:\Program Files\nodejs\npx)
[Wayland:env]   git      : ?  (C:\Program Files\Git\cmd\git.exe)
[Wayland:env]   Shell    : C:\Program Files\Git\usr\bin\bash.exe
[Wayland:env]   Git/usr  : OK (C:\Program Files\Git\usr\bin)
[Wayland:env]   cygpath  : OK (C:\Program Files\Git\usr\bin\cygpath.exe)
[Wayland:env] ════════════════════════════════════════════════════

Correction: an earlier draft of this report transcribed the node/npm/npx/git status markers as ✓ (confirmed present). That was a transcription error on the reporter's part. The actual byte in the log file is a literal ASCII ? (0x3f, verified with hexdump) — not a checkmark, not a mangled Unicode glyph, an actual question mark. That is a distinct, separate finding worth its own line: Wayland's own startup diagnostic does not actually confirm node/npm/npx/git are functional — it prints ? for all four, in contrast to Git/usr and cygpath two lines below, which print a clear OK. Whatever check backs the ? marker is either not implemented, not wired up on Windows, or intentionally emitting "unknown," but a first-run user reading this block gets no real signal for the four tools most relevant to Bash/MCP failures on this machine.

Independent of that diagnostic line, node.exe and npx are confirmed present on disk at the listed paths by a different mechanism: later in the same log, Wayland itself invokes C:\Program Files\nodejs\npx and C:\Program Files\nodejs\node when spawning MCP servers (see the quoting bug below) — it can only fail to invoke them the way it does if they exist at those paths. So the underlying claim ("the toolchain is present, Bash's failure isn't a missing-dependency problem") still holds; it's just backed by the MCP-spawn evidence, not by the ? line.

Steps to reproduce

1. Open Wayland on Windows, start a new chat on Wayland Core.
2. Ask the agent to use the Bash tool (e.g. "use the bash tool and test it works").
3. Agent calls the Bash tool.

That's it — no special command is needed. A trivial command (echo, pwd, etc.) reproduces this every time.

Actual behavior

All three Bash tool calls made in the reproduction session failed. None returned output. None failed fast — every one hung until something external killed it, and the three kills disagree with each other:

Attempt	Result logged
1	Failed to execute command: sandbox child timed out (no duration reported; log timestamps show ~75s elapsed between call and failure)
2	Command timed out after 10000ms
3	Command timed out after 5000ms

Raw log excerpt (2026-07-15.log):

[2026-07-15 16:59:00.535] [info]  [WCoreManager] info: Tool call: Bash
[2026-07-15 17:00:15.616] [info]  [WCoreManager] info: [Bash error] Failed to execute command: sandbox child timed out
[2026-07-15 17:00:25.199] [info]  [WCoreManager] info: Tool call: Bash
[2026-07-15 17:00:35.216] [info]  [WCoreManager] info: [Bash error] Command timed out after 10000ms
[2026-07-15 17:00:42.739] [info]  [WCoreManager] info: Tool call: Bash

Same failures, visible in the chat UI (screenshot attached, wayland-bash-failures-transcript.jpg): three "Running a command" steps, all marked failed, with the exact error text shown per attempt.

The agent gave up after three attempts and told the user Bash "isn't responding in this session."

Expected behavior

A Bash tool call running a trivial builtin should return in well under a second. Per Wayland's own README: "Acts through built-in tools (Read, Write, Edit, Bash, Grep, Glob, Spawn)... inside a native per-OS sandbox." The sandbox executing the command should not need more information than it currently gets to run echo hi.

Root cause

Settings → Wayland Core → Security & Permissions → Env-Passthrough Allowlist (screenshot attached, wayland-core-security-settings.jpg):

No env vars are passed to the sandbox yet. Add a non-secret name below.
(placeholder text: e.g. GITHUB_TOKEN_NAME, PATH, NODE_ENV (no secrets))

This is a default-empty allowlist that gates what environment variables reach the sandboxed child process the Bash tool spawns into. With it empty, PATH is not forwarded. Git Bash's MSYS runtime, launched with no PATH and effectively no environment, does not fail cleanly — it hangs, consistent with the observed "sandbox child timed out" behavior on the first attempt rather than an immediate "command not found."

This is corroborated by an independent, same-class bug logged during the same session: MCP servers spawned via npx/node fail on every attempt with:

[mcp stderr] 'C:\Program' is not recognized as an internal or external command,
[mcp stderr] operable program or batch file. server=C:\Program Files\nodejs\npx

paired with:

(node:17996) [DEP0190] DeprecationWarning: Passing args to a child process with shell
option true can lead to security vulnerabilities, as the arguments are not escaped,
only concatenated.

That is the textbook Windows unquoted-path-with-spaces bug: spawning C:\Program Files\nodejs\npx through shell: true without quoting the executable path splits it at the first space. Wayland's own detected shell for Bash is C:\Program Files\Git\usr\bin\bash.exe — a path with the exact same space-in-"Program Files" shape. Whether the Bash tool's hang is caused by this same unescaped-shell-spawn defect, by the empty env-passthrough allowlist, or both compounding, the result is the same: Windows users get an unusable Bash tool with no actionable error, only a timeout.

Documented spec vs. observed behavior (the smoking gun)

The official docs (not just inference from logs) make this unambiguous. Two separate, specific claims in Bash and Tool Isolation are contradicted by what actually happened on this machine:

1. PATH is supposed to pass through automatically, unconditionally, regardless of any user-configured allowlist:

"The environment is now built by env_passthrough::build_sandboxed_env, which: Passes through locale, terminal, and toolchain-discovery variables (PATH, HOME, LANG, TERM, USER, SHELL, and similar)."

This is documented as always-on, separate from the operator-declared passthrough list shown in Settings. Yet the Settings UI reads "No env vars are passed to the sandbox yet" with zero vars configured, and the Bash tool cannot resolve/run bash.exe on Windows. Either build_sandboxed_env's default toolchain list isn't reaching the AppContainerBackend on Windows, or the Windows spawn path bypasses it — both are engine defects relative to the documented contract.

2. The documented default timeout is 120,000 ms (2 minutes), max 600,000 ms (10 minutes) — the observed timeouts don't match this or any other documented value:

"The tool accepts an optional timeout parameter in milliseconds. The default is 120,000 ms (2 minutes); the maximum is 600,000 ms (10 minutes)."

Observed on this machine, three consecutive calls, same session:

Attempt	Documented default	Actually observed
1	120,000 ms	~75,000 ms ("sandbox child timed out", no ms figure logged)
2	120,000 ms	10,000 ms
3	120,000 ms	5,000 ms

None of these three durations match the documented BashTool default (120,000 ms) or even the separate AppContainerBackend fallback default from the Shell Sandbox doc ("The default timeout is 60 seconds when the manifest does not specify one"). Three different values across three identical, back-to-back calls, none of which correspond to any number in the documentation, indicates the timeout being applied to the Windows sandbox child is neither the documented BashTool default nor a stable value at all — something in the Windows path is either overriding it per-attempt or computing it incorrectly.

Combined, these two spec deviations fully explain the bug: Bash spawns into an environment missing the very variables (PATH) it's documented to always receive, the process hangs instead of failing fast, and it gets killed by a timeout far shorter than documented — with no error message pointing at either root cause.

Why this is worse than it looks

• The timeout is not consistent (75s-ish / 10000ms / 5000ms across three consecutive identical calls in one session), so there is no reliable "just wait longer" workaround, and no setting exposed anywhere in the UI to change it.
• The failure mode is a hang, not an error — for a shell tool, that's the worst possible failure mode, since it's indistinguishable from "still running" until it isn't.
• The one place that could explain this (Security & Permissions → Env-Passthrough Allowlist) is not surfaced anywhere near the Bash tool toggle itself (Tools → Bash: "Run shell commands in the sandbox"), so a user has no reason to connect "Bash doesn't work" to "the sandbox env allowlist is empty" without log-diving.
• config.toml silently ignores keys that look exactly like what a user would try to hand-edit to fix this (see below), with zero feedback that the edit had no effect.

Additional issues found during investigation (same root area, filing here for context — split out if preferred)

1. config.toml silently swallows unknown/mis-sectioned keys with no error surfaced to the user, including keys a user chasing this exact bug would plausibly try to set:

   WARN ignoring unknown or mis-sectioned config key `builtin_tools` ...
   WARN ignoring unknown or mis-sectioned config key `memory.?.provider` ...
   WARN ignoring unknown or mis-sectioned config key `security.block_private_urls` ...
   

   These only appear in the log file, never in the UI.

2. Egress firewall is off by default with the UI itself flagging it: "Egress firewall OFF — the engine can send data to any host and outbound exfiltration is not gated." This contradicts the README's claim of a sandbox "behind a single egress chokepoint" — the chokepoint exists but ships disabled.

3. Every npx/node-based bundled MCP server fails to connect on every launch (firecrawl, perplexity, docker, chrome-devtools, filesystem, image-generation, and others), all via the same unquoted-path spawn defect, logged as generic "Transport error: MCP stdio server exited before responding" — giving no indication to the user that the real cause is a Windows path-quoting bug.

Verified directly on the affected machine (not inferred from Wayland's own output)

Everything above about node/npm/npx/git came from Wayland's own log output, which this report already flags as an unreliable ? marker. So these were independently re-checked by running commands directly in a real PowerShell session on the same Windows machine:

node -v      → v22.23.1
npm -v       → 10.9.8
npx -v       → 10.9.8
git --version → git version 2.55.0.windows.3
bash --version (C:\Program Files\Git\usr\bin\bash.exe) → GNU bash, version 5.3.15(1)-release (x86_64-pc-cygwin)
OS           → Microsoft Windows NT 10.0.19045.0

All four tools exist on disk and are independently confirmed executable outside of Wayland — node -v, npm -v, npx -v, and git --version all returned clean version output with no errors. This closes the loop on the earlier ?-marker finding: it's not that the tools are missing or broken on this machine, it's that Wayland's own diagnostic doesn't check them, and the sandbox doesn't forward them to Bash.

One more real discrepancy worth noting: the system's real node -v is v22.23.1, while Wayland's own [Wayland:env] block reports Node : v24.15.0 (built-in). These are two different Node runtimes — v24.15.0 is Electron's bundled Node, v22.23.1 is the one actually on PATH — which is normal for an Electron app, but worth flagging since it means "Node version" means two different things depending on which part of Wayland you ask.

No WAYLAND_*, ANTHROPIC_*, or OPENAI_* environment variables are set at the user/system level — consistent with credentials being stored via the OS keychain / in-app rather than env vars, per the README.

The documented workaround was tested and does not fix this

WAYLAND_ALLOW_NO_SANDBOX=1 (see the env var audit below) was set at User scope, and — critically — the environment refresh was done properly and thoroughly: Explorer was restarted, then the user separately logged off and back on, and separately did a full machine reboot. Wayland was relaunched fresh after each. The Bash tool was retested after the variable was confirmed active. Result: identical failure.

[2026-07-15 17:39:41.484] [info] [WCoreManager] info: Tool call: Bash
[2026-07-15 17:40:56.567] [info] [WCoreManager] info: [Bash error] Failed to execute command: sandbox child timed out

75,083 ms elapsed — nearly identical to the very first failure recorded in this report (~75,081 ms), same exact error string. This was tested with the variable verifiably live (confirmed via a freshly-spawned process reading it back correctly post-refresh), so this is not an environment-propagation artifact: the documented WAYLAND_ALLOW_NO_SANDBOX=1 opt-out, which per Shell Sandbox should fall back to a non-namespaced NoSandboxBackend, has no effect on this failure. Either the engine isn't honoring this variable on Windows the way it's documented to, or the actual hang isn't coming from AppContainerBackend namespace isolation at all — meaning the sandbox backend itself was never the bottleneck, and the earlier env-passthrough / WSL-shadowing hypotheses in this report are more likely candidates than the sandbox layer itself. There is currently no working workaround for this bug.

Reproduced independently on a second machine, different Windows version — this is not a one-off local misconfiguration

The user reports reproducing this exact issue, with the exact same symptom (Bash tool hangs then times out, same error), on two separate physical machines: the one documented throughout this report (Windows 10 build 19045), and a second machine running Windows 11. On both machines, the problem is reported as isolated specifically to Wayland-Core/the Bash tool — no other applications, shells, or tools on either machine exhibit anything comparable. This rules out a one-off corrupted install, a machine-specific driver/AV interference issue, or an unusual local Windows configuration as the explanation, and points to a defect in Wayland-Core's Windows sandbox/Bash execution path itself, reproducible across at least two independent Windows versions.

(Note: this cross-machine claim is user-reported and was not independently re-verified on the second machine by whoever compiled this report, since only the Windows 10 machine was directly accessible for the investigation above. It's included because it materially changes the picture — a single-machine bug and a two-machine, two-OS-version bug warrant very different triage priority — but a maintainer may reasonably ask for logs from the second machine too.)

Full environment variable audit (Process / User / Machine scope)

Windows resolves environment variables across three scopes (Process, User, Machine) that get merged at login/process-launch time. All three were enumerated directly on the affected machine to rule out anything Wayland-specific being masked by scope, and to check for anything that could independently explain the hang.

Wayland/engine-specific variables found:

Variable	Scope	Value	Meaning
WAYLAND_ALLOW_NO_SANDBOX	User	0 (later corrected to 1 for testing, see above)	Per the Shell Sandbox docs, setting this to 1 explicitly opts the engine out of the real OS sandbox (bwrap/sandbox-exec/AppContainer) and falls back to NoSandboxBackend, which still scrubs env and applies the denylist but skips namespace isolation. Flipping it to 1 (tested above, with a fully verified environment refresh) did not fix the hang.

No WAYLAND_BASH_ALLOW_NETWORK, WAYLAND_SANDBOX, WAYLAND_VAULT_PASSPHRASE, WAYLAND_VAULT_PASSPHRASE_FD, WAYLAND_SEND_MESSAGE_HOST_DELEGATE, WAYLAND_WEB_BACKEND, or WAYLAND_HOME are set at any scope. No ANTHROPIC_API_KEY / OPENAI_API_KEY at OS level either — consistent with the earlier finding that credentials are stored via the OS keychain / in-app, not env vars.

A genuinely new finding — bare bash resolves to the wrong binary, and it's 120x slower:

HOME is not a native Windows environment variable — Windows only sets HOMEDRIVE (C:) and HOMEPATH (\Users\s3np4); Git Bash/MSYS synthesizes HOME from those internally. The Bash-isolation docs list HOME as one of the variables always passed through — worth flagging that "pass through HOME" is a Unix-centric default that has no direct Windows equivalent to pass through in the first place, unless the passthrough code specifically composes it from HOMEDRIVE+HOMEPATH on Windows. Not confirmed as broken, just a platform gap worth checking in the source.

Separately, and more concretely: Get-Command bash -All on this machine resolves, in PATH order, to:

1. C:\Windows\system32\bash.exe        <-- WSL launcher stub (90,112 bytes, dated 5/23/2026)
2. C:\Program Files\Git\usr\bin\bash.exe   <-- the actual Git Bash Wayland detected and shows in its own diagnostic
3. C:\Program Files\Git\bin\bash.exe
4. C:\Users\s3np4\AppData\Local\Microsoft\WindowsApps\bash.exe

C:\Windows\system32\bash.exe is the built-in WSL launcher — invoking bare bash (no path) on this machine does not run Git Bash, it runs WSL. wsl -l -v confirms two registered distros, both currently Stopped: Ubuntu (WSL2, default) and docker-desktop (WSL2). Invoking bare bash therefore triggers a cold WSL VM boot.

This was measured directly, unsandboxed, on the same machine:

bare `bash -c "echo hi"`                         → 7,127 ms  (boots the stopped WSL2 Ubuntu instance)
`C:\Program Files\Git\usr\bin\bash.exe -c "echo hi"` (explicit path) → 60 ms

A ~120x difference, and that's the unsandboxed case, which still completes. Wayland's own log independently confirms WSL-related process spawns already time out on this exact machine, outside of any Bash tool call:

[2026-07-15 17:08:53.381] [info] [AcpDetector] WSL presence check: not available:
spawnSync C:\WINDOWS\system32\cmd.exe ETIMEDOUT

Putting this together: if the Bash tool's sandbox child resolves the command by bare name (bash) via PATH rather than the exact absolute path Wayland's own startup diagnostic already found (C:\Program Files\Git\usr\bin\bash.exe), it would hit the stopped-WSL cold-boot path first. A restrictive AppContainer sandbox plausibly blocks or slows whatever RPC/named-pipe WSL's launcher needs to reach the LxssManager service — which would turn a 7-second unsandboxed cold boot into an indefinite hang, killed only by whichever inconsistent timeout happens to be in effect (see the ~75s / 10,000 ms / 5,000 ms figures earlier in this report). This is not confirmed against source (that would require reading wcore-tools/src/bash.rs), but it is a concrete, reproducible, independently-corroborated candidate that should be checked alongside the env-passthrough and timeout findings above — resolving bash by its known absolute path instead of a bare PATH lookup would be a one-line, low-risk fix if this is indeed what's happening. Note: since WAYLAND_ALLOW_NO_SANDBOX=1 (which removes the AppContainer layer entirely) did not fix the hang, this WSL-shadowing theory now looks like the stronger of the two candidates.

General PATH hygiene, for completeness: the effective Process PATH is 7,414 characters across 155 entries, with 59 duplicate entries (e.g. C:\Program Files\Git\usr\bin appears 4 times, C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common 4 times, C:\Program Files\Docker\Docker\resources\bin 4 times). This isn't a Wayland bug — it's typical accumulation from multiple installers appending to PATH over time — but a PATH this large does add measurable overhead to every CreateProcess call that has to search it, on top of everything else in this report.

Cross-checked against ferroxlabs/wayland-core and its docs — the config schema mismatch is real and provable

The live config.toml Wayland Desktop actually wrote for this install (C:\Users\s3np4\AppData\Roaming\wayland-core\config.toml) was read directly off disk:

[budget]
max_wall_time_secs = 1200
max_tool_runtime_secs = 600

[security]
enabled = false
block_private_urls = false

[tools]
allow_list = [ "Archive", "AskUserQuestion", "Bash", "Delegate", "Edit", ... ]

[builtin_tools.script]
enabled = true

[default]
approval_mode = "auto-edit"

[memory]
provider = "mem0"

[mcp.servers."io.modelcontextprotocol-server-filesystem"]
transport = "stdio"
command = "C:\\Program Files\\nodejs\\npx"
args = [ "@modelcontextprotocol/server-filesystem@0.6.2", "C:\\Users\\s3np4" ]
...

Compared against the authoritative, engine-verified schema at docs.getwayland.com/reference/config-toml (explicitly described there as "verified against the engine"), the documented sections are only: [default], [providers.<name>], [profiles.<name>], [tools], [session], [compact], [file_cache], [plan], [mcp.servers.<name>], [observability]. Documented [default] keys are only provider, model, max_tokens, max_turns — approval_mode is not among them. [budget], [security], [builtin_tools], and [memory] do not exist anywhere in the documented schema at all.

This lines up exactly with the "unknown or mis-sectioned config key" warnings from the log:

WARN ignoring unknown or mis-sectioned config key `builtin_tools`
WARN ignoring unknown or mis-sectioned config key `memory.?.provider`
WARN ignoring unknown or mis-sectioned config key `security.block_private_urls`

Conclusion: this is not a user config mistake, it's Wayland Desktop and Wayland Core disagreeing with each other. The Desktop app's Settings UI (Security & Permissions, IJFW Memory, Tools toggles) writes [builtin_tools.script], [memory].provider, and [security].block_private_urls straight into config.toml — and the Core engine's own parser, which only recognizes the schema published at docs.getwayland.com, throws all three away as unrecognized. Every toggle a user flips in those three Settings panels is silently a no-op at the engine level. [security].enabled and [budget].* are not flagged as unknown in the log, but they're also not in the documented schema — meaning either the docs are incomplete for those two, or they're similarly ignored without even a warning, which would be worse.

This also matters directly for the Bash timeout inconsistency documented above: [budget].max_tool_runtime_secs = 600 (600,000 ms) is sitting in the same undocumented, possibly-inert [budget] section as the keys confirmed to be dropped. If [budget] is being silently ignored the same way [builtin_tools] and [memory] are, that would explain why none of the three observed Bash timeouts (~75,000 ms / 10,000 ms / 5,000 ms) match either the documented BashTool default (120,000 ms) or this configured value (600,000 ms) — the config knob a user would reach for to fix this doesn't reach the engine at all.

Version note: this Wayland install runs Wayland-Core v0.12.25 (per Settings → Wayland Core → Overview). The latest tag published on github.com/FerroxLabs/wayland-core at the time of this report is v0.10.0 (June 8, 2026). The public repo is meaningfully behind what's actually bundled in the Desktop app, so this report's cross-check against the public repo's docs/schema should be read as "the last publicly verifiable contract," not a guarantee that v0.12.25 behaves identically — if this bug was already fixed or introduced between 0.10.0 and 0.12.25, it wouldn't be visible from the public repo.

One more live signal, found while re-checking the config path just now: C:\Users\s3np4\AppData\Roaming\wayland-core\ currently contains a fresh crash sentinel file, .dirty-death.4200, in addition to the one already logged earlier in this investigation (.dirty-death.12492). Two unclean-shutdown sentinels have accumulated over the course of a single investigation session — this points to an ongoing stability problem beyond just the Bash tool, though it's out of scope to fully diagnose here.

Evidence attached

• 2026-07-15.log — full session log from C:\Users\s3np4\AppData\Roaming\Wayland\logs
• wayland-bash-failures-transcript.jpg — chat UI showing all three Bash failures expanded, with exact error strings
• wayland-core-security-settings.jpg — Security & Permissions page showing the empty env-passthrough allowlist
• wcore-config.toml — the live config file, with all API keys and bearer tokens redacted to [REDACTED] before inclusion here

(Attachments to be added manually before submitting — drag the files into this box.)

Severity

Critical, not just high. The Bash tool is one of the six always-on, auto-run "File & Code" tools shown in Settings, advertised as core to what makes Wayland "a full agent in its own right." On Windows it is completely non-functional out of the box, on at least two independent machines across two Windows versions (10 and 11). This isn't a matter of interpretation — it's a direct, verifiable violation of Wayland's own published spec on two independent counts (default env passthrough, default timeout), documented at docs.getwayland.com, not just something inferred from log-reading. It fails silently/slowly rather than with an actionable error, the fix (env-passthrough allowlist) is not discoverable from the Bash tool's own settings entry, and the one documented escape hatch (WAYLAND_ALLOW_NO_SANDBOX=1) was tested — properly, with a verified environment refresh — and does not work either. There is currently no known way for an affected Windows user to get a working Bash tool short of a code fix from FerroxLabs.