Repository navigation
"install" command does not work for opencode in windows 11 #221
Description
codebase-memory-mcp install
codebase-memory-mcp install 0.6.0
Error: Argument or option not valid - "eq".
Write"TASKKILL /?" for use.
Detected agents: Claude-Code VS-Code
Claude Code:
skills: 0 installed
mcp: C:/Users/Icaruk/.claude/.mcp.json
mcp: C:/Users/Icaruk/.claude.json
hooks: PreToolUse (code discovery gate)
hooks: SessionStart (MCP usage reminder on startup/resume/clear/compact)
VS Code:
mcp: C:/Users/Icaruk/AppData/Roaming/Code/User/mcp.json
PATH already includes C:/Users/Icaruk/.local/bin
Install complete. Restart your shell or run:
source C:/Users/Icaruk/.profile
opencode -v
1.3.17
pwsh -v
7.6.0
(gcm opencode).Source
C:\Users\Icaruk\AppData\Local\mise\installs\npm-opencode-ai\1.3.17\opencode.ps1
claude code is not installed.
Opencode is installed using mise, maybe that makes opencode not detectable?
Activity
DeusData commentedon Apr 7, 2026
Hey, thx for reporting 🙏 Will tackle this asap after the 15th. Hope you can wait until then
ipatalas commentedon Apr 16, 2026
I am experiencing exactly the same. Just tried installing codebase-memory-mcp and it doesn't see my opencode.
My opencode is installed via scoop package manager. I don't know how the detection work but I have opencode files in the following directories:
However it's not added to my Apps & Features so if detection works by checking the registry then I guess that's the reason.
I use Windows 11 25H2 and Opencode 1.4.6.
Happy to help debugging if you can't reproduce.
DeusData commentedon May 31, 2026
Two distinct problems in your report:
Error: Argument or option not valid - "eq"(TASKKILL). That came from the install step killing stale MCP processes via a shelltaskkill /FI "IMAGENAME eq …"string that got re-split on Windows. On currentmainthis runs through_spawnvpwith a proper argv array (no shell re-parsing), so the "eq" error should be gone. Please confirm on v0.7.0.opencode not detected (installed via mise). Root cause:
find_in_pathonly probed the bare nameopencode, but on Windows the executable is aopencode.cmd/.ps1/.exeshim — so it was invisible. Fixed:find_in_pathnow also tries.exe/.cmd/.bat/.ps1per PATH entry (commit just pushed).Could you retest
installon v0.7.0? If opencode still isn't detected, please share(gcm opencode).Source(you already did —…\mise\…\opencode.ps1) and whether that dir is on%PATH%. Keeping open pending your retest. 🙏fix(cli): probe Windows PATHEXT variants in find_in_path (#221)
DeusData commentedon May 31, 2026
Thanks for the report. Root cause:
find_in_path(used to discover CLIs likeopencodeduring install) only probed the bare executable name. On Windows, executables carry an extension and CLIs are commonly installed as.cmd/.ps1/.exeshims (via mise, npm, etc.), so the bare-name probe never matched — opencode was present on PATH but the installer couldn't find it.Fixed in commit 0485d3f: on Windows,
find_in_pathnow probes the common PATHEXT variants (.exe,.cmd,.bat,.ps1) for each PATH entry before moving on.Verified compiling and passing on Windows in CI (the
build-windowsandtest-windowsjobs are green with this change). This ships in the next release — after updating,installshould discover opencode on Windows 11. Thanks again!fix(cli): probe Windows PATHEXT variants in find_in_path (DeusData#221)
C3ntraX commentedon Jun 11, 2026
@DeusData is this released in 0.7.0 ?
I have the same issue:
I tried to install it, after the quick install without ui failed too
C3ntraX commentedon Jun 12, 2026
Okay, some more Info:
I uninstalled, cleaned everything and installed the non ui version again (0.8.1) - same errror:
Then I used the install command - same error:
But somehow, the agent was added to the "msp.json"
And it worked somehow?
DeusData commentedon Jun 12, 2026
Thanks for the thorough follow-up and screenshots — and for retesting on 0.8.1. Will investigate the Windows install error path; the fact that the mcp.json entry lands correctly despite the error is a useful clue.
test(repro): GLR blowup #471 + opencode PATHEXT guard #221
18 remaining items
cobrabr commentedon Sep 12, 2026
I can confirm it's working now, I installed it yesterday and it did recognize OpenCode (I didn't install it with
mise, though).DeusData commentedon Sep 19, 2026
Thank you for retesting and for explicitly noting that your working installation does not use mise. That confirms the non-mise setup works for you, but does not establish that the original shim/PATH case is fixed. I have removed awaiting-reporter and am keeping this open for the original integration path rather than closing it on a different configuration. Thanks again for providing that distinction.
DeusData commentedon Sep 26, 2026
Thank you to everyone who kept retesting this across mise, scoop and npm installs! We found a concrete remaining cause, in two parts:
%PATH%into a 4 KB buffer. When the process PATH is 4,096 characters or longer, which is common on Windows machines with many dev tools, the search skips the whole PATH instead of only the tail.%APPDATA%\npm, scoopshimsor miseshims.That fits why it varies from machine to machine. We'll fix both. If you can, the output of
[Environment]::GetEnvironmentVariable('PATH','Process').Lengthfrom an affected session would confirm the first part.fix(cli): search full PATH and probe Windows npm/mise/scoop shim dirs (…
wcy12378 commentedon Sep 27, 2026
Building on the 2026-09-26 root-cause analysis: submitted #2381 which (1) makes
find_in_pathduplicate PATH into a heap buffer sized to the real value instead of the fixed 4 KB stack copy, and (2) givescbm_find_clia Windows-aware fallback list (%APPDATA%\npm,%LOCALAPPDATA%\mise\shims,%USERPROFILE%\scoop\shims) with PATHEXT probing. Happy to adjust the exact shim dirs if your Windows CI prefers different layouts.fix(cli): read PATH at its real length and probe Windows shim dirs (D…
DeusData commentedon Oct 1, 2026
Thank you, @wcy12378, for following up with #2381 and for responding to the review there. Linking it here as the current fix candidate so everyone following the Windows installer report can find the work. It is still open, so this issue stays open too; this is not a claim that the remaining setups are fixed. The newer validation questions and Windows CI rerun request on the PR still need maintainer follow-up. Thanks again to everyone who supplied the different install layouts.
fix(platform): cbm_env_dup answers through the settings resolver (Deu…
test(cli): run the DeusData#221 long-PATH and Windows shim regression…
DeusData commentedon Oct 25, 2026
Thank you for the continued Windows install evidence and for #2381. The fix candidate needs maintainer follow-up on its outstanding validation; another generic PATHEXT retest would not add to the concrete shim/PATH cases already supplied. Keeping this open without claiming those remaining setups are fixed. Sorry for the delay—this is waiting on maintainer follow-up, and I’ll follow up soon.
Merge pull request #2381 from wcy12378/fix/221-windows-cli-detection
DeusData commentedon Oct 25, 2026
The fix for both remaining causes is now on main in ced508f (#2381 - thank you, @wcy12378). The installer's PATH search now reads PATH at its real length instead of skipping the whole PATH once it passes 4,096 characters, and CLI detection now also probes %APPDATA%\npm, %LOCALAPPDATA%\mise\shims and %USERPROFILE%\scoop\shims, including .cmd, .exe, .bat and .ps1 shims. Both cases are covered by regression tests that run on every CI leg, Windows included. Thank you, @Icaruk, and everyone who kept retesting across mise, scoop and npm setups - those layouts are what pinned this down. The fix will be in the next release. If install still misses opencode on your machine after that, please comment here with the output of [Environment]::GetEnvironmentVariable('PATH','Process').Length and where opencode is installed, and we will reopen and pick it straight back up.