Activity

1. IuriGuerreiro

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Apr 18, 2026
2. timm-u commented on Apr 18, 2026

   

   timm-u

   on Apr 18, 2026

   More actions

   OpenCode provider false "not installed / not on PATH" on Windows

   Summary

   T3 Code Nightly reports:

   OpenCode CLI (`opencode`) is not installed or not on PATH.
   

   But OpenCode is installed and works normally from PowerShell / terminal:

   opencode --version
   # 1.4.11

   This looks like a Windows-specific process spawning issue. T3 Code's OpenCode version check works through a shell, but the OpenCode server startup uses direct no-shell spawning. The default opencode binary path resolves to an npm shim on Windows, which works in a terminal but does not work with direct spawn("opencode", ...).

   Environment

   • OS: Windows
   • T3 Code: 0.0.21-nightly.20260417.58
   • T3 Code commit: 9df3c640210f
   • Product: T3 Code (Nightly)
   • OpenCode: 1.4.11
   • OpenCode install method:

   curl -fsSL https://opencode.ai/install | bash

   What Works

   From PowerShell:

   opencode --version
   # 1.4.11

   Get-Command opencode -All resolves to npm shims:

   C:\Users\<user>\AppData\Roaming\npm\opencode.ps1
   C:\Users\<user>\AppData\Roaming\npm\opencode.cmd
   C:\Users\<user>\AppData\Roaming\npm\opencode
   

   The actual native OpenCode executable exists here:

   %APPDATA%\npm\node_modules\opencode-ai\node_modules\opencode-windows-x64\bin\opencode.exe
   

   In my case:

   C:\Users\krist\AppData\Roaming\npm\node_modules\opencode-ai\node_modules\opencode-windows-x64\bin\opencode.exe
   

   Reproduction Steps

   1. On Windows, install OpenCode:

   curl -fsSL https://opencode.ai/install | bash

   2. Confirm terminal can run it:

   opencode --version
   # 1.4.11

   3. Open T3 Code Nightly.
   4. Enable/configure the OpenCode provider with the default binary path:

   opencode
   

   5. T3 Code reports:

   Not found - OpenCode CLI (`opencode`) is not installed or not on PATH.
   

   Expected Behavior

   T3 Code should detect and launch OpenCode successfully when opencode works in the user's terminal and is on PATH.

   Actual Behavior

   T3 Code reports OpenCode as not installed / not on PATH.

   Root Cause

   The packaged app appears to use inconsistent Windows process launch behavior for OpenCode.

   The version check uses shell mode on Windows:

   function runOpenCodeCommand(input) {
     const child = spawn(input.binaryPath, [...input.args], {
       stdio: ["ignore", "pipe", "pipe"],
       shell: process.platform === "win32",
       env: process.env
     });
   }

   But server startup does not:

   function startOpenCodeServerProcess(input) {
     const child = spawn(input.binaryPath, args, {
       stdio: ["ignore", "pipe", "pipe"],
       env: {
         ...process.env,
         OPENCODE_CONFIG_CONTENT: JSON.stringify({})
       }
     });
   }

   On Windows, spawn("opencode", ..., { shell: false }) fails with ENOENT because the global npm installation provides a .cmd / .ps1 shim, not an opencode.exe directly on PATH.

   Local Verification

   I reproduced the behavior with Node:

   spawn("opencode", ["--version"], { shell: false })
   // error: spawn opencode ENOENT
   
   spawn("opencode", ["--version"], { shell: true })
   // stdout: 1.4.11

   Directly spawning the native OpenCode binary works:

   spawn(
     "C:/Users/krist/AppData/Roaming/npm/node_modules/opencode-ai/node_modules/opencode-windows-x64/bin/opencode.exe",
     ["serve", "--hostname=127.0.0.1", "--port=48984"],
     {
       shell: false,
       env: {
         ...process.env,
         OPENCODE_CONFIG_CONTENT: "{}"
       }
     }
   )

   This successfully started the server:

   opencode server listening on http://127.0.0.1:48984
   

   User Workaround

   Set T3 Code's OpenCode binary path to the native executable instead of opencode:

   %APPDATA%\npm\node_modules\opencode-ai\node_modules\opencode-windows-x64\bin\opencode.exe
   

   For example, in:

   %USERPROFILE%\.t3\userdata\settings.json
   

   Add:

   {
     "providers": {
       "opencode": {
         "binaryPath": "C:\\Users\\<user>\\AppData\\Roaming\\npm\\node_modules\\opencode-ai\\node_modules\\opencode-windows-x64\\bin\\opencode.exe"
       }
     }
   }

   After setting that path, T3 Code reports OpenCode as ready:

   {
     "provider": "opencode",
     "enabled": true,
     "installed": true,
     "version": "1.4.11",
     "status": "ready",
     "message": "4 upstream providers connected through OpenCode."
   }

   Suggested Fix

   Option A: Use shell mode for OpenCode server startup on Windows

   This is the smallest behavior-consistent fix, since runOpenCodeCommand() already uses shell: process.platform === "win32".

   const child = spawn(input.binaryPath, args, {
     stdio: ["ignore", "pipe", "pipe"],
   + shell: process.platform === "win32",
     env: {
       ...process.env,
       OPENCODE_CONFIG_CONTENT: JSON.stringify({})
     }
   });

   Option B: Resolve opencode to the native OpenCode executable before spawning

   For npm installs, the native binary is usually under one of these paths:

   %APPDATA%\npm\node_modules\opencode-ai\node_modules\opencode-windows-x64\bin\opencode.exe
   %APPDATA%\npm\node_modules\opencode-ai\node_modules\opencode-windows-x64-baseline\bin\opencode.exe
   

   This avoids shell usage but requires package-specific resolution logic.

   Option C: Add shared Windows CLI spawning logic

   If the configured binary resolves to .cmd / .bat, invoke it through shell mode; otherwise use direct spawn.

   Pseudo-code:

   function spawnCli(binaryPath: string, args: string[], options: SpawnOptions) {
     if (process.platform !== "win32") {
       return spawn(binaryPath, args, options);
     }
   
     const ext = path.extname(binaryPath).toLowerCase();
   
     if (ext === ".cmd" || ext === ".bat") {
       return spawn(binaryPath, args, {
         ...options,
         shell: true,
       });
     }
   
     return spawn(binaryPath, args, options);
   }

   Note: this still does not cover the default binaryPath: "opencode" unless command lookup first resolves the shim path.

   Why This Matters

   The UI tells users OpenCode is not installed even when it is installed correctly and works from the terminal. The provider can be made fully functional by pointing T3 Code at the underlying opencode.exe, so this appears to be a Windows process spawning / npm shim resolution issue rather than an OpenCode installation problem.
3. timm-u commented on Apr 18, 2026

   

   timm-u

   on Apr 18, 2026

   More actions

   Just for info - my commented findings / fix works. I have opencode working on my local T3 code build. Should anyone want to quickly get it working locally:

   
4. IuriGuerreiro

   changed the title [-][Bug]: Nightly - OpenCode is not detected in windows[/-] [+][Bug]: Nightly - OpenCode provider false "not installed / not on PATH" on Windows[/+] on Apr 18, 2026
5. IuriGuerreiro commented on Apr 18, 2026

   

   IuriGuerreiro

   on Apr 18, 2026

   Author

   More actions

   Thank you for the workarround, I changed the title for a better description of the problem, I was trying to figure it out the problem, but didn't had time to do it

   👍React with 👍1Reacted by timm-u
6. loxoron218 commented on Apr 18, 2026

   

   loxoron218

   on Apr 18, 2026

   Last edited by loxoron218

   More actions

   This issue appears to also affect the Arch Linux build from the AUR (t3code-nightly-bin v0.0.21-nightly).

   For me, I can't add the opencode path on the settings page (/usr/bin/opencode), as the text fields can't be edited at all. I wonder if the "Checking provider status - Waiting for the server to report installation and authentication details." messages on all providers, which I don't have installed on my system, have anything to do with it.

   Moreover, I can't toggle any provider on/off on the settings page.
7. adammansfield

   added a commit that references this issue on Apr 18, 2026

   fix: opencode is not on PATH on Windows (pingdotgg#2163)

   fc012cd
8. adammansfield commented on Apr 18, 2026

   

   adammansfield

   on Apr 18, 2026

   Contributor

   More actions

   @loxoron218 That seems like a separate bug because I can edit the OpenCode binary path, and I do not see the messages:

   "Checking provider status - Waiting for the server to report installation and authentication details."

   Original OpenCode (ran with the latest commit):
   
   and the path can be editted:
   
   and I can toggle the providers:
   

   😕React with 😕1Reacted by loxoron218
9. adammansfield commented on Apr 20, 2026

   

   adammansfield

   on Apr 20, 2026

   Contributor

   More actions

   This bug has been partially fixed in v0.0.21-nightly.20260420.77 if the opencode installation is an opencode.exe. For example if installed using bun:

   bun add -g opencode-ai
   where.exe opencode
   # C:\Users\adam\.bun\bin\opencode.exe
   

   But it is still broken as of v0.0.21-nightly.20260420.77 if the opencode installation is an opencode.cmd. For example if installed using npm:

   npm i -g opencode-ai
   where.exe opencode
   # C:\Program Files\nodejs\opencode
   # C:\Program Files\nodejs\opencode.cmd
   

   I have updated my pull request #2183 to fix the narrower opencode.cmd issue.
10. adammansfield commented on Apr 24, 2026

    

    adammansfield

    on Apr 24, 2026

    Contributor

    More actions

    This bug with opencode.cmd no longer just occurs in nightly, but also now in v0.0.21.
11. juliusmarminge

    closed this as completedin #2183on May 1, 2026