gemini-cli - 💡(How to fix) Fix feat: Native support for pnpm global installation (fix symlink resolution)

What would you like to be added?

We would like @google/gemini-cli to officially support global installation via pnpm (pnpm add -g @google/gemini-cli).

Currently, installing the CLI with pnpm breaks at runtime, throwing Error: Cannot find module exceptions. To achieve full compatibility, the CLI needs to properly resolve its internal paths and sub-packages (like core utilities or HTTP clients) when hosted within a symlinked, non-hoisted environment, rather than relying on a flat node_modules structure.

Why is this needed?

Many developers and DevOps teams have completely migrated to pnpm as their single, unified package manager due to its speed and disk space efficiency.

Right now, if a pnpm user wants to use this CLI locally without downloading it every time, they are forced to use a workaround like npm install -g. This breaks their workflow, forces them to maintain two different global package managers, and creates messy path configurations (mixing npm's global folder with pnpm's global bin directory).

Running the CLI via npx or pnpm dlx works, but it introduces a noticeable network latency on every single command execution, which ruins the fast-paced experience expected from a terminal tool.

Additional context

This compatibility gap has become even more prominent with the release of pnpm 11.3, which completely decouples pnpm from the npm CLI and restructures how global binaries are managed natively on the system (AppData\Local\pnpm on Windows and ~/.local/share/pnpm on Unix).

The issue usually stems from internal packages or dependencies not being explicitly declared in the specific package.json that requires them, or from hardcoded path resolutions that fail to traverse symlinks. Making the CLI's entry point resilient to symlinks (using robust tools like require.resolve) would fix this for pnpm users without affecting npm or yarn users at all.