Fix Windows Studio agent runtime issues

[simidaaa]

This PR fixes several Windows-specific Studio runtime issues found while running the project locally.

Changes:

• Detect local agents on Windows with where.exe instead of which.
• Allow probing .cmd / .exe based CLIs such as Codex and Claude Code.
• Filter Windows process termination noise so PID/system messages do not pollute chat output.
• Preserve UTF-8 filenames in multipart uploads, including Chinese attachment names.
• Avoid crashing the Studio server when an SSE request errors after headers were already sent.
• Remove chmod from the CLI build script so the workspace builds on Windows.
• Use the currently published @powerformer/vela-cli version available on npm.

Verified locally on Windows:

• pnpm install
• pnpm -r build
• Studio agent scan detects Claude Code and Codex CLI
• Codex CLI message through Studio no longer emits PID noise
• Chinese filename upload is preserved

[lefarcen]

Heads-up: PR #3 is also open against the same Windows runtime path. Both PRs touch packages/cli/package.json, packages/cli/src/studio-server.ts, packages/runtime/src/detect.ts, and packages/runtime/src/spawn.ts, and both look to be addressing the Studio-on-Windows agent/runtime breakage.

Sharing this so effort doesn't get split invisibly — comparing approaches with #3 will probably make the maintainer review path a lot clearer.

[lefarcen]

Heads-up: PR #11 is also open against the same Windows/runtime area, and the overlap is real — both PRs touch packages/cli/src/studio-server.ts, packages/runtime/src/spawn.ts, and packages/runtime/package.json, including the filename-preservation / stdout-decoding path around issue #9. Sharing so the two approaches can be compared before either lands.

[nettee]

@simidaaa I'm holding off on generating review comments for #10 because this pull request has merge conflicts right now.

Please resolve the conflicts with main and push the updated branch. Once that's done, request or wait for the review to run again and I'll take another look.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[lefarcen]

Heads-up: PR #29 is also open against the same Windows Studio runtime path. Both PRs touch packages/runtime/src/detect.ts and packages/runtime/src/spawn.ts around where-based detection and Windows CLI launch behavior.

Sharing this so the approaches can be compared before maintainers decide what lands.

[lefarcen]

Heads-up @simidaaa — PR #34 (by @kacimiamine) was just opened to address issue #27, and it makes the exact same chmod +x dist/bin.js removal in packages/cli/package.json as part of your diff here. Your PR is broader (Windows runtime detection, where.exe, .cmd probing), so the scopes don't fully overlap — but the chmod hunk is identical. The maintainer team will pick which approach lands; sharing so neither effort gets wasted. 👀

[walliai666]

I'm seeing compatibility problems on Windows as well. May I ask when this PR is going to be merged?

[lefarcen]

Hey @walliai-chenlb — thanks for adding another Windows datapoint. This PR is still touching the right area (packages/runtime/src/detect.ts / packages/runtime/src/spawn.ts), but it is not merge-ready yet: the branch still needs a rebase onto main, and the maintainer team is also comparing a few overlapping Windows/runtime fixes before deciding what lands.

So I can't give you a reliable merge date yet. If you can share your Windows version plus which CLI flow is failing for you, that context would help the maintainers judge which patch covers the real compatibility gap fastest.

[walliai666]

@lefarcen Thanks for the reply. I'm running Windows 10 Pro 22H2 (OS Build 19045.6466). I've encountered and fixed these compatibility issues:

1. chmod +x is a Unix-only command, causing CLI package build failure. Fixed by using fs.chmodSync instead.
2. The which command is unavailable on Windows, leading to total agent detection failure. Replaced which with where.
3. .cmd files cannot be executed directly via execFile, resulting in agent version detection failure. Added shell: true as a fix.
4. Running .cmd files with spawn throws an ENOENT error when starting agent processes. Resolved by enabling shell: true.

[lefarcen]

Hey @walliai-chenlb — this is really helpful detail, thank you. The four Windows-specific failures you listed line up with the exact hot spots in this PR (packages/cli/package.json, packages/runtime/src/detect.ts, and packages/runtime/src/spawn.ts), so this gives the maintainers a much clearer validation target for the Windows path.

The main blocker is still that PR #10 needs a clean rebase onto main before the maintainer comparison/review pass can move forward. If you notice one more concrete datapoint meanwhile, the most useful one would be whether your local fix also makes the full Studio agent launch path work end-to-end — not just detection/version probing, but actually starting the CLI from Studio on Windows.

[walliai666]

@lefarcen After applying the fixes, the CLI can be launched normally on Windows. The entire process from video generation to export works perfectly.

[lefarcen]

Hey @walliai-chenlb — perfect, this is the datapoint I was hoping to get. End-to-end Windows validation (CLI launch → video generation → export) is much stronger evidence than detection-only checks, and it lines up with the exact paths this PR changes in packages/runtime/src/detect.ts, packages/runtime/src/spawn.ts, and packages/cli/src/studio-server.ts.

The maintainer-side blocker is still the same: PR #10 needs to be rebased cleanly onto main before the comparison/review pass can move forward. But your result makes the Windows runtime case here much clearer for that next pass. 🙌

[walliai666]

@lefarcen I've noticed the conflicts on PR #10. Unfortunately I'm not the original submitter, so I'm unable to rebase the branch and resolve conflicts. Feel free to let me know if you need any further testing after the issues are fixed.

[lefarcen]

Hey @walliai-chenlb, thanks for flagging this — that makes sense.

Since you’re not the original branch owner, there isn’t much more we can ask you to do on the rebase side; the remaining blocker is for the original submitter or a maintainer to refresh the branch against main and resolve the conflicts.

Really appreciate the offer to help test again once that lands. If the branch gets updated, we’ll follow up here for another Windows pass.

[walliai666]

@lefarcen No problem. I'll keep an eye on this thread and be ready to re-test once the branch is updated.

[lefarcen]

Heads-up: PR #48 is also open against this same Windows build-script bug. Both PRs touch packages/cli/package.json and replace the Unix-only chmod +x dist/bin.js step that breaks pnpm -r build on Windows.

PR #48 keeps that fix narrowly scoped to the CLI build path, while this branch also carries the wider Windows runtime changes. Sharing this so the overlap is visible before maintainers choose which path lands.