Question 1

Why do migrated hooks fail with 'Hook timed out after Xms' error in Gemini CLI?

Accepted Answer

`gemini hooks migrate` copies the `timeout` value from Claude Code settings without converting units. Claude Code measures hook timeout in **seconds**, but Gemini CLI expects **milliseconds**, so a timeout of `30` (30 seconds) becomes 30 milliseconds and almost any hook command times out.

**Workaround (until fixed):** After running `gemini hooks migrate`, manually multiply each hook's `timeout` value by 1000 in the generated Gemini settings:

```json
// Claude Code (seconds)
"timeout": 30

// Gemini CLI (milliseconds)
"timeout": 30000
```

If you never set an explicit `timeout`, you are unaffected — both products default to 60 seconds / 60000 ms.

**Proper fix:** The migrator in `packages/cli/src/commands/hooks/migrate.ts` should convert the unit: `migrated["timeout"] = hook["timeout"] * 1000;`. Affects `gemini-cli` 0.57.0.

Question 2

Why does Gemini CLI replace ${VAR} environment variable placeholders in settings.json with literal values after startup?

Accepted Answer

Known bug (#29556) in Gemini CLI ≤0.63.0-nightly: when a deprecated key is auto-migrated at startup, the whole containing subtree (e.g. `ui`, `general`) is rewritten from the expanded settings view, so sibling keys like `"autoThemeSwitching": "${TEST_AUTO_THEME:-false}"` are saved as literal `true`/`false` and the variable stops working. Fix: upgrade to a build that includes PR #29564, which changes `migrateDeprecatedSettings` in `packages/cli/src/config/settings.ts` to read/modify `originalSettings` (the raw file view) instead of the expanded `settings` view, preserving `${VAR}` placeholders on disk while keeping runtime values expanded. Workarounds until then: (1) manually migrate deprecated keys yourself before startup so no migration runs on that subtree — e.g. replace `ui.accessibility.disableLoadingPhrases: true` with `ui.accessibility.enableLoadingPhrases: false` plus `ui.loadingPhrases: "off"`; (2) re-edit `~/.gemini/settings.json` after migration to restore the `${VAR:-default}` placeholders; (3) keep `${VAR}` keys out of subtrees that still contain deprecated keys. Affected migrations: `general.disableAutoUpdate`, `general.disableUpdateNag`, `context.fileFiltering.disableFuzzySearch`, `ui.accessibility.enableLoadingPhrases`, `tools.approvalMode`, and `experimental.*`.

Question 3

Why does Gemini in VS Code write files to the wrong project folder when using WSL?

Accepted Answer

This is a confirmed path-resolution bug (issue #25527): with VS Code + WSL, if your workspace root is a broad parent directory containing multiple repositories, Gemini can resolve relative paths against the wrong repo. The UI shows the expected relative path under your active project, but the file is actually written to a different repository (e.g., /home/user/repogit/other-repo/tests/file.txt instead of the current project's tests folder). Workaround confirmed by the reporter: open the specific project folder directly as the VS Code workspace root (File > Open Folder > your project, e.g. /home/jacques/repogit/mmm-tools/FLUX) instead of a parent directory or multi-root workspace — with a single project as root, files are created in the correct location. As extra safety until the official fix ships, pass absolute paths in your prompts and verify the file's actual location on disk after Gemini reports success.

Question 4

Why is my Gemini CLI extension not showing up in the geminicli.com extension gallery?

Accepted Answer

The gallery crawler is an external service (not part of the gemini-cli codebase) that crawls daily, so there is no user-side fix for indexing lag. First verify the requirements: (1) the repository is public and not archived, disabled, or a fork; (2) the GitHub topic `gemini-cli-extension` is set; (3) a valid `gemini-extension.json` manifest exists at the root of the default branch (main or master). Then validate the manifest locally with a recent Gemini CLI release (e.g., 0.61.0) — note that passing local validation does not guarantee gallery indexing. If your extension is still absent from https://geminicli.com/extensions.json after several daily crawl cycles, open an issue in google-gemini/gemini-cli and ask the gallery team to confirm whether the repo was discovered, failed validation, or was skipped, since validation errors are not currently surfaced to extension authors.

gemini-cli

Core Features

What It Can't Do

Use Cases

Tags

Getting Started

Similar Projects