Question 1

마이그레이션된 hooks가 Gemini CLI에서 'Hook timed out after Xms' 오류로 실패하는 이유는 무엇인가요?

Accepted Answer

`gemini hooks migrate`는 Claude Code 설정에서 `timeout` 값을 단위 변환 없이 복사합니다. Claude Code는 훅 타임아웃을 **초** 단위로 측정하지만 Gemini CLI는 **밀리초** 단위를 사용하므로, `30`(30초)의 타임아웃이 30밀리초가 되어 거의 모든 훅 명령이 타임아웃됩니다.

**임시 해결 방법(수정될 때까지):** `gemini hooks migrate`를 실행한 후, 생성된 Gemini 설정에서 각 훅의 `timeout` 값에 수동으로 1000을 곱하세요:

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

// Gemini CLI (밀리초)
"timeout": 30000
```

명시적인 `timeout`을 설정한 적이 없다면 영향을 받지 않습니다. 두 제품 모두 기본값은 60초 / 60000ms입니다.

**올바른 수정:** `packages/cli/src/commands/hooks/migrate.ts`의 마이그레이터는 단위를 변환해야 합니다: `migrated["timeout"] = hook["timeout"] * 1000;`. `gemini-cli` 0.57.0에 영향을 미칩니다.

Question 2

왜 Gemini CLI가 시작 후 settings.json의 ${VAR} 환경 변수 플레이스홀더를 리터럴 값으로 대체하나요?

Accepted Answer

Gemini CLI ≤0.63.0-nightly의 알려진 버그(#29556): 시작 시 더 이상 사용되지 않는 키가 자동으로 마이그레이션되면 해당 키가 속한 전체 하위 트리(예: `ui`, `general`)가 확장된 설정 뷰에서 다시 작성되므로, `"autoThemeSwitching": "${TEST_AUTO_THEME:-false}"`와 같은 형제 키가 리터럴 `true`/`false`로 저장되어 변수가 더 이상 작동하지 않게 됩니다. 해결 방법: `packages/cli/src/config/settings.ts`의 `migrateDeprecatedSettings`를 변경하여 확장된 `settings` 뷰 대신 `originalSettings`(원시 파일 뷰)를 읽고 수정하도록 한 PR #29564가 포함된 빌드로 업그레이드하세요. 이렇게 하면 런타임 값은 확장된 상태로 유지하면서 디스크의 `${VAR}` 플레이스홀더가 보존됩니다. 그때까지의 임시 해결 방법: (1) 시작 전에 더 이상 사용되지 않는 키를 직접 수동으로 마이그레이션하여 해당 하위 트리에서 마이그레이션이 실행되지 않도록 합니다. 예를 들어 `ui.accessibility.disableLoadingPhrases: true`를 `ui.accessibility.enableLoadingPhrases: false`와 `ui.loadingPhrases: "off"`로 교체합니다. (2) 마이그레이션 후 `~/.gemini/settings.json`을 다시 편집하여 `${VAR:-default}` 플레이스홀더를 복원합니다. (3) `${VAR}` 키를 여전히 더 이상 사용되지 않는 키가 포함된 하위 트리에 두지 않습니다. 영향을 받는 마이그레이션: `general.disableAutoUpdate`, `general.disableUpdateNag`, `context.fileFiltering.disableFuzzySearch`, `ui.accessibility.enableLoadingPhrases`, `tools.approvalMode`, `experimental.*`.

Question 3

WSL을 사용할 때 VS Code의 Gemini가 잘못된 프로젝트 폴더에 파일을 작성하는 이유는 무엇인가요?

Accepted Answer

이것은 확인된 경로 해석 버그입니다(issue #25527): VS Code + WSL 환경에서 워크스페이스 루트가 여러 리포지토리를 포함하는 넓은 상위 디렉터리인 경우, Gemini가 상대 경로를 잘못된 리포지토리를 기준으로 해석할 수 있습니다. UI에는 활성 프로젝트 아래의 예상되는 상대 경로가 표시되지만, 파일은 실제로 다른 리포지토리에 작성됩니다(예: 현재 프로젝트의 tests 폴더 대신 /home/user/repogit/other-repo/tests/file.txt). 보고자가 확인한 우회 방법: 상위 디렉터리나 멀티 루트 워크스페이스 대신 특정 프로젝트 폴더를 VS Code 워크스페이스 루트로 직접 여세요(File > Open Folder > 해당 프로젝트, 예: /home/jacques/repogit/mmm-tools/FLUX). 단일 프로젝트를 루트로 설정하면 파일이 올바른 위치에 생성됩니다. 공식 수정이 배포될 때까지 추가 안전 조치로, 프롬프트에서 절대 경로를 전달하고 Gemini가 성공을 보고한 후 파일의 디스크상 실제 위치를 확인하세요.

Question 4

Gemini CLI 확장이 geminicli.com 확장 갤러리에 표시되지 않는 이유는 무엇인가요?

Accepted Answer

갤러리 크롤러는 매일 크롤링하는 외부 서비스(gemini-cli 코드베이스에 포함되지 않음)이므로 인덱싱 지연에 대한 사용자 측 해결 방법은 없습니다. 먼저 요구 사항을 확인하세요: (1) 리포지토리가 공개 상태이며 아카이브되거나 비활성화되었거나 포크된 상태가 아닙니다. (2) GitHub 토픽 `gemini-cli-extension`이 설정되어 있습니다. (3) 유효한 `gemini-extension.json` 매니페스트가 기본 브랜치(main 또는 master)의 루트에 존재합니다. 그런 다음 최신 Gemini CLI 릴리스(예: 0.61.0)로 매니페스트를 로컬에서 검증하세요. 로컬 검증을 통과해도 갤러리 인덱싱이 보장되는 것은 아닙니다. 여러 번의 일일 크롤링 주기가 지난 후에도 확장 프로그램이 https://geminicli.com/extensions.json에 여전히 표시되지 않으면 google-gemini/gemini-cli에 이슈를 열고 갤러리 팀에 리포지토리가 발견되었는지, 검증에 실패했는지, 아니면 건너뛰었는지 확인해 달라고 요청하세요. 현재 검증 오류는 확장 프로그램 작성자에게 표시되지 않기 때문입니다.

gemini-cli

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트