Sandbox Dockerfile is on node:20-slim (EOL 2026-04-30), though #1038 moved it to Node 22 in 2025

Hello, and thank you for Gemini CLI.

The sandbox image is built on Node 20, which reached end-of-life three months ago. What made me want to raise it rather than skip it is that you appear to have moved *off* Node 20 once already.

## What I observed

The repository-root `Dockerfile` uses Node 20 for both stages, including the final one:

```
2: FROM docker.io/library/node:20-slim AS builder
42: FROM docker.io/library/node:20-slim <-- final runtime stage
94: ENTRYPOINT ["/usr/local/share/npm-global/bin/gemini"]
```

**Node 20 reached end-of-life on 2026-04-30.** Supported lines are 22, 24 and 26.

## The part I can't explain, and am not going to guess at

[#1038 "Dockerfile: Node 22 and ENTRYPOINT"](https://github.com/google-gemini/gemini-cli/pull/1038) was **merged on 2025-06-14** — *"Upgrade to Node 22"*. Today the file is on Node 20.

I traced back as far as the 2026-05-04 refactor (`b6fc583b0`, "make Dockerfile self-contained with multi-stage build") and it was already `node:20-slim` before that commit, so that refactor isn't the cause. Something between June 2025 and then moved it back and **I have not established what**, so I'm reporting the current state rather than a story about how it got there. You'll know the history better than I can reconstruct it.

## Why it matters for this image in particular

Node states the consequence directly:

> "It's important to note that **End-of-Life versions are always affected** when a security release occurs."

June 2026 fixed twelve CVEs into 22.x/24.x/26.x, with 20.x excluded — including **CVE-2026-48933** (HIGH, WebCrypto AES integer overflow → remote process abort) and **CVE-2026-48618** (HIGH, Unicode dot separator → TLS wildcard-depth authentication bypass), plus TLS host-identity and mTLS authorization bypasses. July 2026, published this week, again patched only 26/24/22.

This is the **sandbox** image — the boundary the CLI runs model-directed commands inside. A boundary is a slightly worse place than most to have a runtime that can no longer receive fixes. I'm stating that as a reason to prioritise, not as a claim that any specific CVE is reachable here.

## What I did NOT check

- I did not pull or scan a published image; this analyses the Dockerfile.
- No reachability or exploitability analysis for any CVE. None is claimed.

## Suggestion

Move both stages to `node:22-slim` or `node:24-slim` — which, if #1038 was the intent, is a return to it rather than a new decision. Happy to open the PR.

*Disclosure: AI-assisted (Claude Opus 5). I verified the live Dockerfile, the #1038 merge, the commit history I cite, the Node EOL dates from endoflife.date and the CVE list from nodejs.org myself before posting.*

Start with the repository-root Dockerfile and compare its two node:20-slim stages with PR #1038 and the cited history. Verify that the sandbox image builds with a supported Node 22 or 24 base; done when neither stage uses the EOL Node 20 image.

Written by the indexing model from the issue text.