Title
Windows shell sandbox still hangs after restart: echo hello, cmd.exe /c echo test, and other trivial commands time out in assistant tool runtime
Summary
I am still seeing a Windows shell execution failure in the assistant tool runtime after restarting Wayland and retrying with a fresh session.
This looks related to the previously reported/fixed issues:
#737
#727
However, in my environment the shell runner still appears to hang before normal command execution. The issue reproduces with trivial commands that should return immediately, including echo hello and explicit cmd.exe invocation.
This suggests the problem is likely in the Windows shell bootstrap / subprocess execution path rather than in the command content itself.
Affected Area
Windows assistant tool runtime
Shell execution layer
Bash/PowerShell/cmd invocation path
Possibly temp working-directory initialization or subprocess I/O handling
Environment
Platform: Windows
Product: Wayland
Session type: assistant session with shell tool access
Current working directory reported by session:
C:\Users\somad\AppData\Roaming\Wayland\wayland\wcore-temp-1783398087752
Restart status: Wayland was restarted before retrying
Reproducibility: consistent across repeated attempts
Regression Context
This report is being filed as a follow-up / possible incomplete fix relative to:
#737
#727
Please check whether those fixes covered:
only one shell execution path
only CLI-level execution
only Bash/PowerShell selection logic
not the embedded assistant sandbox runtime on Windows
At the moment, the embedded tool execution path still appears non-functional in my setup.
Problem Statement
Any shell command attempt hangs until timeout, including commands with:
no external dependencies
no filesystem dependency beyond session startup
no meaningful stdout volume
no complex quoting or shell syntax
The failure then cascades into the Wayland safety system, which stops the turn after repeated failures:
Stopped a runaway loop
A command failed 4 times in a row, so this turn was stopped to avoid burning tokens retrying it. You can send a new message to continue.
That runaway-loop message seems to be a secondary protection mechanism, not the root cause.
Minimal Reproduction
Steps
Launch or restart Wayland on Windows
Open a fresh assistant session
Execute a minimal shell command through the shell/Bash tool
Observe whether output is returned
Repro commands tested
Test 1
echo "hello from wayland sandbox"
Test 2
echo test
Test 3
cmd.exe /c echo test
Test 4
echo hello
Expected Behavior
Each command should complete almost immediately and return stdout, e.g.:
hello from wayland sandbox
test
hello
Actual Behavior
All tested commands timed out without returning output.
Observed timeouts:
echo "hello from wayland sandbox" → timed out after 10s
echo test → timed out after 30s
cmd.exe /c echo test → timed out after 30s
echo hello → timed out after 15s
After repeated failures, the system triggered runaway-loop protection and aborted further retries for that turn.
Why This Is Likely Infrastructure-Level, Not Command-Level
- Command complexity is effectively zero
These are the simplest possible commands. They do not depend on:
repo state
network
file parsing
interpreter startup beyond shell launch
large output handling
If even echo hello blocks, the failure is almost certainly below the user command layer.
- Multiple execution styles fail
The issue is not limited to one syntax or one shell abstraction:
plain shell invocation fails
explicit cmd.exe /c ... also fails
That reduces the likelihood of a quoting/parsing bug in just one wrapper.
- Fresh restart did not resolve it
This suggests the problem is not just a stale assistant state in the UI. It may be:
process bootstrap failure
environment initialization deadlock
inaccessible working directory
broken subprocess/stdout capture path
4. Timeout occurs before observable command completion
The shell runner appears to stall before producing stdout, even for immediate-return commands. That points to process startup, IPC, or working-directory validation.
Likely Failure Points
Below are the most plausible technical causes based on the symptoms.
A. Shell subprocess launch deadlock
The parent process may spawn the shell but block on:
process initialization
pipe attachment
stdout/stderr readers
completion wait
startup handshake
B. Working directory invalid / locked / inaccessible
The reported session working directory is:
C:\Users\somad\AppData\Roaming\Wayland\wayland\wcore-temp-1783398087752
If that directory:
does not exist at execution time
exists but is locked
has ACL/access issues
is partially deleted/stale
causes shell startup to block
then even trivial commands could fail before actual execution.
C. Windows shell bootstrap/profile loading issue
If the runtime launches through PowerShell, Bash, or a wrapper that loads startup configuration, it could be hanging during:
profile loading
environment setup
shell detection/fallback
path resolution
shell wrapper initialization
D. Assistant runtime path differs from the path fixed in #737/#727
The previous fixes may have addressed:
CLI invocation
one shell family only
one runtime path only
while the assistant’s embedded tool execution path still uses a different Windows process-launch stack.
E. Stdout/stderr capture blockage
If the subprocess starts but the runtime deadlocks on reading output streams or waiting for exit, simple commands would also appear hung.
F. Timeout / watchdog behavior masks underlying spawn error
The shell runner may actually be failing immediately, but the tool wrapper could be waiting incorrectly and surfacing everything as a timeout instead of surfacing the real subprocess error.
Technical Signals That Would Help Diagnose
The following diagnostics would probably make the root cause much easier to isolate:
Process-launch details
exact executable invoked (bash, powershell, pwsh, cmd.exe, wrapper binary)
command-line arguments
whether CreateProcess / child spawn succeeded
child PID if created
Working directory validation
whether the runtime verified the cwd exists before spawn
whether path normalization or escaping is altering the path
whether shell spawn succeeds with a neutral cwd like %TEMP% or C:
Pipe and I/O telemetry
whether stdout/stderr pipes were attached successfully
whether any bytes were ever read
whether the parent process blocked waiting on pipe readers
Timeout classification
whether the timeout occurred:
before child creation
after child creation but before first output
after output but before process exit
Shell selection logs
which shell path was selected
whether fallback logic ran
whether PowerShell/Bash/cmd detection behaved as expected
Error surfacing
whether there is an internal spawn/access error being swallowed and later presented as a generic timeout
Suggested Diagnostic Matrix
If the team wants to isolate the failing layer quickly, these checks may help:
- Force known-good working directories
Try shell execution with:
C:
%TEMP%
a newly created test folder
the current session temp dir
If only the session temp dir fails, cwd setup is likely involved.
- Compare shells explicitly
Test:
cmd.exe /c echo test
powershell.exe -NoProfile -Command "Write-Output test"
pwsh.exe -NoProfile -Command "Write-Output test"
If cmd.exe also hangs, the issue is likely below PowerShell-specific logic.
- Disable profile loading
If PowerShell is in the chain, ensure tests also use:
powershell.exe -NoProfile -NonInteractive -Command "Write-Output test"
4. Log child process lifecycle
Record:
spawn start timestamp
spawn success/failure
first stdout timestamp
exit timestamp
timeout timestamp
5. Test without session temp dir
If the assistant runtime can temporarily force a neutral cwd, compare results.
- Surface raw spawn errors
If there is an exception or OS-level error code, exposing that instead of generic timeout would make the issue much easier to report accurately.
User-Visible Impact
This issue blocks any workflow depending on shell execution, including:
simple command execution
project inspection when shell fallback is needed
build/test flows
debugging workflows
automation steps
multi-step coding tasks inside the assistant runtime
In effect, the shell tool is unusable in this Windows environment.
Scope Clarification Request
Please confirm whether #737 and #727 were intended to fix:
Wayland CLI shell execution only
PowerShell/Bash invocation generally
assistant embedded shell tool execution on Windows as well
Because from the user side, the embedded assistant execution path still behaves as broken.
Requested Follow-Up
Please investigate this as:
a regression,
an incomplete fix,
or a separate Windows assistant-runtime subprocess bug
with reference to:
#737
#727
I would especially appreciate guidance on any debug build, logging flag, or diagnostic mode that can capture:
shell chosen
cwd used
spawn result
child PID
stdout/stderr attachment
timeout stage
Copy-Paste Short Repro Block
Environment:
- Windows
- Wayland assistant session
- Restarted app before retrying
Working directory:
C:\Users\somad\AppData\Roaming\Wayland\wayland\wcore-temp-1783398087752
Minimal repro commands:
- echo "hello from wayland sandbox" -> timeout after 10s
- echo test -> timeout after 30s
- cmd.exe /c echo test -> timeout after 30s
- echo hello -> timeout after 15s
Observed follow-up error:
"Stopped a runaway loop. A command failed 4 times in a row, so this turn was stopped to avoid burning tokens retrying it."
Expected:
Immediate stdout from trivial commands
Actual:
Shell hangs / times out before returning output
Title
Windows shell sandbox still hangs after restart: echo hello, cmd.exe /c echo test, and other trivial commands time out in assistant tool runtime
Summary
I am still seeing a Windows shell execution failure in the assistant tool runtime after restarting Wayland and retrying with a fresh session.
This looks related to the previously reported/fixed issues:
#737
#727
However, in my environment the shell runner still appears to hang before normal command execution. The issue reproduces with trivial commands that should return immediately, including echo hello and explicit cmd.exe invocation.
This suggests the problem is likely in the Windows shell bootstrap / subprocess execution path rather than in the command content itself.
Affected Area
Windows assistant tool runtime
Shell execution layer
Bash/PowerShell/cmd invocation path
Possibly temp working-directory initialization or subprocess I/O handling
Environment
Platform: Windows
Product: Wayland
Session type: assistant session with shell tool access
Current working directory reported by session:
C:\Users\somad\AppData\Roaming\Wayland\wayland\wcore-temp-1783398087752
Restart status: Wayland was restarted before retrying
Reproducibility: consistent across repeated attempts
Regression Context
This report is being filed as a follow-up / possible incomplete fix relative to:
#737
#727
Please check whether those fixes covered:
only one shell execution path
only CLI-level execution
only Bash/PowerShell selection logic
not the embedded assistant sandbox runtime on Windows
At the moment, the embedded tool execution path still appears non-functional in my setup.
Problem Statement
Any shell command attempt hangs until timeout, including commands with:
no external dependencies
Stopped a runaway loopno filesystem dependency beyond session startup
no meaningful stdout volume
no complex quoting or shell syntax
The failure then cascades into the Wayland safety system, which stops the turn after repeated failures:
A command failed 4 times in a row, so this turn was stopped to avoid burning tokens retrying it. You can send a new message to continue.
That runaway-loop message seems to be a secondary protection mechanism, not the root cause.
Minimal Reproduction
hello from wayland sandbox test hello Actual Behavior All tested commands timed out without returning output.Steps
Launch or restart Wayland on Windows
Open a fresh assistant session
Execute a minimal shell command through the shell/Bash tool
Observe whether output is returned
Repro commands tested
Test 1
echo "hello from wayland sandbox"
Test 2
echo test
Test 3
cmd.exe /c echo test
Test 4
echo hello
Expected Behavior
Each command should complete almost immediately and return stdout, e.g.:
Observed timeouts:
echo "hello from wayland sandbox" → timed out after 10s
echo test → timed out after 30s
cmd.exe /c echo test → timed out after 30s
echo hello → timed out after 15s
After repeated failures, the system triggered runaway-loop protection and aborted further retries for that turn.
Why This Is Likely Infrastructure-Level, Not Command-Level
These are the simplest possible commands. They do not depend on:
repo state
network
file parsing
interpreter startup beyond shell launch
large output handling
If even echo hello blocks, the failure is almost certainly below the user command layer.
The issue is not limited to one syntax or one shell abstraction:
plain shell invocation fails
explicit cmd.exe /c ... also fails
That reduces the likelihood of a quoting/parsing bug in just one wrapper.
This suggests the problem is not just a stale assistant state in the UI. It may be:
process bootstrap failure
environment initialization deadlock
inaccessible working directory
broken subprocess/stdout capture path
4. Timeout occurs before observable command completion
The shell runner appears to stall before producing stdout, even for immediate-return commands. That points to process startup, IPC, or working-directory validation.
Likely Failure Points
Below are the most plausible technical causes based on the symptoms.
A. Shell subprocess launch deadlock
The parent process may spawn the shell but block on:
process initialization
C:\Users\somad\AppData\Roaming\Wayland\wayland\wcore-temp-1783398087752 If that directory:pipe attachment
stdout/stderr readers
completion wait
startup handshake
B. Working directory invalid / locked / inaccessible
The reported session working directory is:
does not exist at execution time
exists but is locked
has ACL/access issues
is partially deleted/stale
causes shell startup to block
then even trivial commands could fail before actual execution.
C. Windows shell bootstrap/profile loading issue
If the runtime launches through PowerShell, Bash, or a wrapper that loads startup configuration, it could be hanging during:
profile loading
environment setup
shell detection/fallback
path resolution
shell wrapper initialization
D. Assistant runtime path differs from the path fixed in #737/#727
The previous fixes may have addressed:
CLI invocation
one shell family only
one runtime path only
while the assistant’s embedded tool execution path still uses a different Windows process-launch stack.
E. Stdout/stderr capture blockage
If the subprocess starts but the runtime deadlocks on reading output streams or waiting for exit, simple commands would also appear hung.
F. Timeout / watchdog behavior masks underlying spawn error
The shell runner may actually be failing immediately, but the tool wrapper could be waiting incorrectly and surfacing everything as a timeout instead of surfacing the real subprocess error.
Technical Signals That Would Help Diagnose
The following diagnostics would probably make the root cause much easier to isolate:
Process-launch details
exact executable invoked (bash, powershell, pwsh, cmd.exe, wrapper binary)
command-line arguments
whether CreateProcess / child spawn succeeded
child PID if created
Working directory validation
whether the runtime verified the cwd exists before spawn
whether path normalization or escaping is altering the path
whether shell spawn succeeds with a neutral cwd like %TEMP% or C:
Pipe and I/O telemetry
whether stdout/stderr pipes were attached successfully
whether any bytes were ever read
whether the parent process blocked waiting on pipe readers
Timeout classification
whether the timeout occurred:
before child creation
after child creation but before first output
after output but before process exit
Shell selection logs
which shell path was selected
whether fallback logic ran
whether PowerShell/Bash/cmd detection behaved as expected
Error surfacing
whether there is an internal spawn/access error being swallowed and later presented as a generic timeout
Suggested Diagnostic Matrix
If the team wants to isolate the failing layer quickly, these checks may help:
Try shell execution with:
C:
%TEMP%
a newly created test folder
the current session temp dir
If only the session temp dir fails, cwd setup is likely involved.
- Compare shells explicitly
cmd.exe /c echo test powershell.exe -NoProfile -Command "Write-Output test" pwsh.exe -NoProfile -Command "Write-Output test" If cmd.exe also hangs, the issue is likely below PowerShell-specific logic.Test:
- Disable profile loading
powershell.exe -NoProfile -NonInteractive -Command "Write-Output test" 4. Log child process lifecycle Record:If PowerShell is in the chain, ensure tests also use:
spawn start timestamp
spawn success/failure
first stdout timestamp
exit timestamp
timeout timestamp
5. Test without session temp dir
If the assistant runtime can temporarily force a neutral cwd, compare results.
If there is an exception or OS-level error code, exposing that instead of generic timeout would make the issue much easier to report accurately.
User-Visible Impact
This issue blocks any workflow depending on shell execution, including:
simple command execution
project inspection when shell fallback is needed
build/test flows
debugging workflows
automation steps
multi-step coding tasks inside the assistant runtime
In effect, the shell tool is unusable in this Windows environment.
Scope Clarification Request
Please confirm whether #737 and #727 were intended to fix:
Wayland CLI shell execution only
PowerShell/Bash invocation generally
assistant embedded shell tool execution on Windows as well
Because from the user side, the embedded assistant execution path still behaves as broken.
Requested Follow-Up
Please investigate this as:
a regression,
an incomplete fix,
or a separate Windows assistant-runtime subprocess bug
with reference to:
#737
#727
I would especially appreciate guidance on any debug build, logging flag, or diagnostic mode that can capture:
shell chosen
cwd used
spawn result
child PID
stdout/stderr attachment
timeout stage
Copy-Paste Short Repro Block
Environment:
Working directory:
C:\Users\somad\AppData\Roaming\Wayland\wayland\wcore-temp-1783398087752
Minimal repro commands:
Observed follow-up error:
"Stopped a runaway loop. A command failed 4 times in a row, so this turn was stopped to avoid burning tokens retrying it."
Expected:
Immediate stdout from trivial commands
Actual:
Shell hangs / times out before returning output