fix(shell): avoid non-string stdout parsing in cygpath path resolution#29384
fix(shell): avoid non-string stdout parsing in cygpath path resolution#29384SpencerJung wants to merge 1 commit into
Conversation
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
|
This PR doesn't fully meet our contributing guidelines and PR template. What needs to be fixed:
Please edit this PR description to address the above within 2 hours, or it will be automatically closed. If you believe this was flagged incorrectly, please let a maintainer know. |
|
The following comment was made by an LLM, it may be inaccurate: Potential duplicate found:
Why it's related: This PR has the identical title and appears to address the same issue with cygpath stdout parsing in the Windows shell path resolution. It's likely an earlier attempt or related fix for the same problem that issue #26932 describes. |
|
This pull request has been automatically closed because it was not updated to meet our contributing guidelines within the 2-hour window. Feel free to open a new pull request that follows our guidelines. |
Issue for this PR
Closes #26932
What does this PR do?
This replaces the spawner.lines(...) call inside packages/opencode/src/tool/shell.ts's Windows cygpath() helper with an explicit spawn() + stdout decode flow.
That keeps stdout as a guaranteed string before calling .split(), and only parses the first line when the subprocess exits successfully. If the helper fails, behavior stays the same and path resolution falls back cleanly.
Why this fixes the issue
The reported crash happens before the shell subprocess actually runs because the output handling path assumes stdout is already a string. By collecting and decoding handle.stdout ourselves, this code no longer depends on that brittle path and avoids the (result.stdout ?? "").split is not a function failure.
Verification
Scope