fix(auth): fix Gemini CLI path detection for global npm installs on Windows#6045
fix(auth): fix Gemini CLI path detection for global npm installs on Windows#6045ehgamemo wants to merge 1 commit intoopenclaw:mainfrom
Conversation
On Windows, the global npm node_modules structure differs from Linux/macOS. This adds the correct search paths to locate oauth2.js when installed globally via npm.
| if (process.platform === "win32") { | ||
| const npmBinDir = dirname(resolvedPath); | ||
| searchPaths.push( | ||
| join( |
There was a problem hiding this comment.
[P1] Windows path derivation assumes resolvedPath is the binary path
On Windows, findInPath("gemini") can resolve to gemini.cmd/gemini.bat, and realpathSync may return that wrapper path. Using dirname(resolvedPath) as npmBinDir then appending node_modules/... assumes the wrapper lives alongside a global node_modules directory (which isn't true for common npm layouts like %APPDATA%\npm\gemini.cmd with modules in %APPDATA%\npm\node_modules). This can make the added Windows search paths miss the real install location.
Consider deriving the global root via npm prefix -g / npm root -g (or walking up from resolvedPath until node_modules is found) rather than assuming dirname(resolvedPath) is the prefix.
Prompt To Fix With AI
This is a comment left during a code review.
Path: extensions/google-gemini-cli-auth/oauth.ts
Line: 97:100
Comment:
[P1] Windows path derivation assumes `resolvedPath` is the binary path
On Windows, `findInPath("gemini")` can resolve to `gemini.cmd`/`gemini.bat`, and `realpathSync` may return that wrapper path. Using `dirname(resolvedPath)` as `npmBinDir` then appending `node_modules/...` assumes the wrapper lives alongside a global `node_modules` directory (which isn't true for common npm layouts like `%APPDATA%\npm\gemini.cmd` with modules in `%APPDATA%\npm\node_modules`). This can make the added Windows search paths miss the real install location.
Consider deriving the global root via `npm prefix -g` / `npm root -g` (or walking up from `resolvedPath` until `node_modules` is found) rather than assuming `dirname(resolvedPath)` is the prefix.
How can I resolve this? If you propose a fix, please make it concise.| if (process.platform === "win32") { | ||
| const npmBinDir = dirname(resolvedPath); | ||
| searchPaths.push( |
There was a problem hiding this comment.
[P3] Windows search paths add maintenance surface without documenting expected layout
This block hardcodes several deep package paths (@google/gemini-cli nested under another node_modules, plus dist/src/... vs dist/...). Given this is compensating for npm/global-install differences, a short comment describing the observed Windows global layout(s) being supported would make it easier to update when Gemini CLI changes packaging.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Prompt To Fix With AI
This is a comment left during a code review.
Path: extensions/google-gemini-cli-auth/oauth.ts
Line: 97:99
Comment:
[P3] Windows search paths add maintenance surface without documenting expected layout
This block hardcodes several deep package paths (`@google/gemini-cli` nested under another `node_modules`, plus `dist/src/...` vs `dist/...`). Given this is compensating for npm/global-install differences, a short comment describing the observed Windows global layout(s) being supported would make it easier to update when Gemini CLI changes packaging.
<sub>Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!</sub>
How can I resolve this? If you propose a fix, please make it concise.|
This pull request has been automatically marked as stale due to inactivity. |
bfc1ccb to
f92900f
Compare
|
Thanks for opening the original fix path here.\n\nClosing this in favor of #27585, which is a clean/refactored continuation for the same root-cause family and includes expanded regression coverage for npm shim layouts.\n\nCredit to @ehgamemo for the foundational original work in this thread; #27585 explicitly carries that attribution forward.\n\nIf any scope here is missing from #27585, reply and we can reopen immediately. |
Description
Problem:
OpenClaw fails to detect Gemini CLI on Windows because it cannot correctly resolve the global npm package path
structure. The relative path between the binary file and node_modules on Windows differs from Linux/macOS, which
prevents the system from reading oauth2.js to retrieve the OAuth configuration.
Changes:
I have modified extensions/google-gemini-cli-auth/oauth.ts to include specific search path logic for Windows
environments. This allows OpenClaw to correctly locate the Gemini CLI credentials file within the global npm
directory.
Greptile Overview
Greptile Summary
This PR updates
extensions/google-gemini-cli-auth/oauth.tsto better locate the Gemini CLI’s bundledoauth2.json Windows by adding additional Windows-only candidate paths derived from the resolvedgeminiexecutable path. The intent is to handle global npm install directory layouts that differ from macOS/Linux so OpenClaw can extract the OAuth client config automatically.Confidence Score: 3/5
process.platform === "win32", but the new logic assumesdirname(resolvedPath)is a global npm prefix; whengeminiresolves to a .cmd/.bat shim in%APPDATA%\npm, the actualnode_modulesroot may be elsewhere, so the fix might not work for all users.(2/5) Greptile learns from your feedback when you react with thumbs up/down!