Extension install (`echo "Y" | gemini extensions install`) fails or hangs when the extension triggers more than one consent prompt — breaks all workflows using the code-review extension

TL;DR

The "Install Gemini CLI" step in action.yml installs extensions with a single piped Y:

echo "Y" | gemini extensions install "${extension}"

On a fresh runner $HOME, gemini extensions install can show two consent prompts: the folder-trust prompt, then the combined third-party/Agent-Skills consent (shown for extensions that declare Agent Skills — gemini-cli-extensions/code-review now does, via its code-review-commons skill). The single Y is consumed by the first prompt; the second read hits EOF and the install aborts with exit 1 (observed in GitHub Actions) or hangs until killed (observed locally). Every workflow that passes the code-review extension via the extensions: input currently fails at the install step.

Piping more Y lines does not help: each consent prompt creates a fresh readline.createInterface over process.stdin and calls rl.close() in the answer callback. Node's readline discards already-buffered stdin bytes on close, so the first prompt swallows the entire pipe and everything after the first line is dropped. The consent read also has no close/EOF handler, so at EOF the promise never resolves — the process aborts or stalls, and the install never succeeds. (Verified in the published npm bundle of 0.46.0, consent.ts region.)

Reproduction (no GitHub Actions needed)

export HOME=$(mktemp -d)   # simulate a fresh CI runner home
echo "Y" | npx --yes @google/gemini-cli@0.50.0 extensions install \
  "https://github.com/gemini-cli-extensions/code-review"

The Y answers the folder-trust prompt, then the install hangs at:

Agent skills inject specialized instructions and domain-specific knowledge ...
Do you want to continue? [Y/n]:

In GitHub Actions the same sequence exits 1 at that prompt instead of hanging, failing the step. Reproduced with Gemini CLI 0.46.0 and 0.50.0 (current latest), always with a fresh $HOME — which is exactly the state of a hosted runner. (Runs where $HOME/.gemini already exists and the folder is trusted can succeed with a single Y, which makes the failure look intermittent; on hosted runners it is deterministic.)

Suggested fix

Use the CLI's documented flag instead of piping input, and close stdin so any future extra prompt fails fast instead of hanging the job:

gemini extensions install --consent "${extension}" </dev/null

--consent ("Acknowledge the security risks of installing an extension and skip the confirmation prompt") is wired as requestConsent = args.consent ? () => Promise.resolve(true) : requestConsentNonInteractive, and that same function is used for both call sites (folder trust and extension/skills consent), so the flag covers every prompt. Verified end-to-end on 0.46.0 and 0.50.0: exit 0, extension installed and enabled in $HOME/.gemini/extensions. There is no env-var or settings-based bypass for the extension consent, and --yolo does not apply (it only governs tool-call approval), so the flag is the only reliable non-interactive path.

Workaround for consumers (until fixed)

Pre-install each extension in a run: step before the run-gemini-cli step, using the command above with the same CLI version, and omit the extensions: input — the CLI automatically loads everything already installed under $HOME/.gemini, whereas passing extensions: re-runs the broken install path.

- name: 'Pre-install extension (non-interactive)'
  env:
    GEMINI_CLI_VERSION: '0.50.0'  # keep in sync with gemini_cli_version below
  run: |-
    npx --yes "@google/gemini-cli@${GEMINI_CLI_VERSION}" extensions install --consent 'https://github.com/gemini-cli-extensions/code-review' </dev/null

Environment

• run-gemini-cli at current main (3ca2577 at time of writing); the echo "Y" | pattern is in the "Install Gemini CLI" step of action.yml
• Gemini CLI 0.46.0 and 0.50.0, ubuntu-latest hosted runners and local Linux
• Extension: gemini-cli-extensions/code-review (any extension declaring Agent Skills will trigger it)

Related

• #532, #510, #519 — adjacent reports where a failure inside the gemini invocation surfaces as a green job with no output. This one at least fails red at the install step; note that after installs are fixed, consumers with a tools.core allowlist also need activate_skill allowlisted or the newly-installed skill can't activate (#532).
• The underlying readline behavior (buffered-stdin discard + no EOF handling in the consent prompt) is arguably its own bug in google-gemini/gemini-cli — happy to file it there too if useful.

Start in action.yml at the "Install Gemini CLI" step and inspect how the extensions input is installed. Replace the piped confirmation approach with the documented non-interactive consent flag and closed stdin, then reproduce with a fresh HOME using the command shown in the issue. Done means the code-review extension installs successfully without hanging or failing on a hosted runner.