[GH-ISSUE #1935] [Feature] Enable verify:gemini-client on native Windows #642

New issue

Closed

opened 2026-10-15 18:26:52 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:26:52 +00:00

Owner

Originally created by @pablodiazjorge on GitHub (Oct 11, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1935

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I removed credentials, tokens, private paths, and sensitive target data.

Area

MCP or agent integration

Current limitation

scripts/verify-gemini-client.mjs stops on win32 before doing anything ("Native Gemini verifier requires POSIX; Windows is unverified"), and docs/testing.md lists native Windows compatibility as unverified for this lane. With the assertion removed, two more things block it on Windows:

npm installs of Gemini CLI have no native executable. Only a gemini.cmd shim reaches PATH, which execFile cannot spawn (spawn gemini ENOENT; Node does not run .cmd files without a shell), and REA_VERIFY_GEMINI_COMMAND accepts a single executable, so there is no way to point the lane at the real entry point, bundle/gemini.js.
Two setup-plan checks build the expected prefix with a hard-coded "/" (join(profile, ".agents", "skills") + "/" and profile + "/"), so they fail against Windows paths.

Use cases

Windows users who register REA in Gemini CLI through rea setup --client gemini_cli have no verified lane behind that path.
Contributors on Windows cannot run the Gemini CLI lane at all.

With the three changes below, the lane passes on native Windows 11 x64 (non-elevated, Node 22.22.3, main at fb43dd97):

Gemini CLI	Mode	Result
0.63.0 (npm install, the version the POSIX lane uses)	call	passed: catalog 172, schemas 172, Evidence seen, skill loaded
0.63.0 (npm install)	chat	passed

Desired outcome and success criteria

npm run verify:gemini-client (call and -- chat) runs and passes on native Windows when REA_VERIFY_GEMINI_COMMAND points at node_modules/@google/gemini-cli/bundle/gemini.js.
A selected .js, .mjs or .cjs entry point runs under the verifier's Node; any other value is spawned as today.
The setup-plan checks use the platform path separator.
When the default gemini cannot be spawned on Windows, the preflight error says which entry point to select.
docs/testing.md records 0.63.0 as verified on native Windows too. The POSIX path does not change.

Authority boundaries and non-goals

No product code changes. The lane keeps its isolated GEMINI_CLI_HOME, separate Git project and loopback Gemini API fixture, so no live API or account is used. Out of scope: running the .cmd shim through a shell, live Google API compatibility (unverified on POSIX too), and the other client verifiers that still assert POSIX.

Alternatives considered

Running the shim with shell: true would put the prompt (which contains a Unicode path) through cmd.exe quoting. Requiring users to wrap Node themselves is not possible with a single-executable variable. Running a selected JavaScript entry point under the verifier's own Node is the smallest change and leaves every existing value working as before.

Possible direction

One focused PR, ready on my side, following the Claude Code lane change in #1926 (#1923). Happy to adjust the scope.

References

scripts/verify-gemini-client.mjs (the win32 assertion, the preflight and the two setup-plan checks)
docs/testing.md, verify:gemini-client section
#1923 and #1926, the same change for the Claude Code lane

Originally created by @pablodiazjorge on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1935 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area MCP or agent integration ### Current limitation `scripts/verify-gemini-client.mjs` stops on win32 before doing anything ("Native Gemini verifier requires POSIX; Windows is unverified"), and `docs/testing.md` lists native Windows compatibility as unverified for this lane. With the assertion removed, two more things block it on Windows: - npm installs of Gemini CLI have no native executable. Only a `gemini.cmd` shim reaches `PATH`, which `execFile` cannot spawn (`spawn gemini ENOENT`; Node does not run `.cmd` files without a shell), and `REA_VERIFY_GEMINI_COMMAND` accepts a single executable, so there is no way to point the lane at the real entry point, `bundle/gemini.js`. - Two setup-plan checks build the expected prefix with a hard-coded `"/"` (`join(profile, ".agents", "skills") + "/"` and `profile + "/"`), so they fail against Windows paths. ### Use cases - Windows users who register REA in Gemini CLI through `rea setup --client gemini_cli` have no verified lane behind that path. - Contributors on Windows cannot run the Gemini CLI lane at all. With the three changes below, the lane passes on native Windows 11 x64 (non-elevated, Node 22.22.3, `main` at `fb43dd97`): | Gemini CLI | Mode | Result | |---|---|---| | 0.63.0 (npm install, the version the POSIX lane uses) | call | passed: catalog 172, schemas 172, Evidence seen, skill loaded | | 0.63.0 (npm install) | chat | passed | ### Desired outcome and success criteria - `npm run verify:gemini-client` (call and `-- chat`) runs and passes on native Windows when `REA_VERIFY_GEMINI_COMMAND` points at `node_modules/@google/gemini-cli/bundle/gemini.js`. - A selected `.js`, `.mjs` or `.cjs` entry point runs under the verifier's Node; any other value is spawned as today. - The setup-plan checks use the platform path separator. - When the default `gemini` cannot be spawned on Windows, the preflight error says which entry point to select. - `docs/testing.md` records 0.63.0 as verified on native Windows too. The POSIX path does not change. ### Authority boundaries and non-goals No product code changes. The lane keeps its isolated `GEMINI_CLI_HOME`, separate Git project and loopback Gemini API fixture, so no live API or account is used. Out of scope: running the `.cmd` shim through a shell, live Google API compatibility (unverified on POSIX too), and the other client verifiers that still assert POSIX. ### Alternatives considered Running the shim with `shell: true` would put the prompt (which contains a Unicode path) through `cmd.exe` quoting. Requiring users to wrap Node themselves is not possible with a single-executable variable. Running a selected JavaScript entry point under the verifier's own Node is the smallest change and leaves every existing value working as before. ### Possible direction One focused PR, ready on my side, following the Claude Code lane change in #1926 (#1923). Happy to adjust the scope. ### References - `scripts/verify-gemini-client.mjs` (the win32 assertion, the preflight and the two setup-plan checks) - `docs/testing.md`, `verify:gemini-client` section - #1923 and #1926, the same change for the Claude Code lane

bsakaguchi

2026-10-15 18:26:52 +00:00