[BUG]: Windows - bun run scripts resolve to opencode.exe instead of the actual tool

[tylerhaddox]

Description

On Windows, bun run <script> inside an opencode session resolves tools like vitest, vue-tsc, eslint, etc. to opencode.exe instead of the actual tool binary in node_modules/.bin/.

Root cause: When node is not on PATH, bun auto-creates a node symlink pointing to the current process executable. Since opencode is a bun --compile standalone, that symlink points to opencode.exe. Any tool with a #!/usr/bin/env node shebang then executes opencode instead of the JS runtime.

Why Claude Code doesn't have this problem: Claude Code's claude.exe overrides the compiled binary metadata (ProductName: Claude Code, blank OriginalFilename). opencode ships with stock bun metadata:

Field	Claude Code	opencode
ProductName	Claude Code	Bun
OriginalFilename	(empty)	bun.exe
FileDescription	Claude Code	Bun
CompanyName	Anthropic PBC	Oven

Verified via (Get-Item opencode.exe).VersionInfo on Windows.

Suggested fix: Customize the exe metadata in the bun build --compile step, similar to how Claude Code does it, so bun's runtime doesn't identify the opencode binary as a bun instance.

Steps to reproduce

1. Install opencode on Windows via winget (no Node.js on PATH)
2. Open an opencode session in a project with vitest (or any node-shimmed tool)
3. Run bun run test (where the script calls vitest)
4. Observe the opencode help/banner output instead of vitest running

Running node_modules/.bin/vitest.exe directly works fine. The issue is only when bun's shell resolves the binary via the auto-created node symlink.

Operating System

Windows 11

Terminal

Windows Terminal (PowerShell 7.x)

OpenCode version

1.2.15 (bun 1.3.10)

[coalaura]

having the same issue, started only with v1.3.10

Edit: A workaround for me was creating a node.cmd somewhere early in my PATH just has:

@echo off
bun %*

[github-actions]

To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.