🤖 fix: prevent spawn bash ENOENT when subagents finish #1352
+11
−1
Conversation
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
When a subagent calls agent_report, the backend deletes its workspace
directory. A race condition occurs because the frontend's GitStatusStore
may have an in-flight executeBash call for that workspace:
1. Subagent reports → backend starts remove()
2. remove() deletes directory from disk
3. Frontend's executeBash arrives, tries to spawn bash with deleted cwd
4. Node.js reports 'spawn bash ENOENT' (misleading - cwd is gone, not bash)
The fix adds a removingWorkspaces guard to executeBash. This set is
populated for the entire duration of remove(), so any bash execution
attempt during removal returns Err('Workspace is being removed').
This is the holistic fix point - all bash execution flows through
executeBash, and the guard covers the full removal window (disk delete
through metadata emit).
We preserve the original disk-first ordering in remove() to maintain
atomicity: if disk deletion fails (and force=false), we abort and keep
the workspace in config so the user can retry. Reordering to invalidate
first would risk orphaned directories on disk.
ethanndickson
force-pushed
the
ethan/fix-subagent-bash-enoent
branch
from
2b418f3 to
dfa6409
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Problem
When a subagent calls
agent_report, a race condition causesspawn bash ENOENTerrors on Linux (and likely other platforms).Error seen:
This looks like bash isn't found, but the real issue is Node.js reporting ENOENT when the cwd doesn't exist (misleading error).
On Linux, this would produce a popup containing the error.
Root Cause
Race between frontend git status polling and backend workspace deletion:
agent_report→ backend startsremove()remove()adds workspaceId toremovingWorkspacessetremove()deletes workspace directory from diskexecuteBashIPC arrives (started before removal)executeBashspawns bash with the deleted cwd → ENOENTThe race is consistent because
agent_reporttriggers a metadata update withtaskStatus: "reported", which the frontend receives and triggers an immediate git status refresh - right as the backend is deleting the directory.Fix
Add a
removingWorkspacesguard toexecuteBash. TheremovingWorkspacesset is populated for the entire duration ofremove()(set at start, cleared in finally block), so any bash execution attempt during removal returnsErr("Workspace is being removed").This is the holistic fix point:
executeBashErrresults gracefullyWhy not reorder remove() to invalidate before deleting?
The original disk-first ordering provides atomicity: if disk deletion fails (and
force=false), we abort and keep the workspace in config so the user can retry. Invalidating first would risk orphaned directories that users can't manage.Generated with
mux• Model:anthropic:claude-opus-4-5• Thinking:high