Gemini CLI v0.67.0: Model listing, container IDE connections

1. View models in the terminal or JSON

Released on November 4, this version lets users query model information with gemini models. gemini models list returns the same list, with a choice of terminal-friendly text or JSON for other programs to process.

The JSON is an array whose entries contain a model identifier, display name, description, and input and output token limits. Scripts can read the list to select or display models, rather than simply check their names.

Model listing finishes before the interactive interface or sandbox initializes. Non-interactive listing, which does not wait for user input, also skips unnecessary authentication refreshes. This keeps refresh logs out of standard output, the default results channel, when piping results to another program.

The original verification procedure provides these JSON output examples after building the package. They use a dedicated query command and a model-listing option, respectively.

node packages/cli/dist/index.js models -o json | jq .
node packages/cli/dist/index.js --list-models -o json | jq .

2. Relay connections between isolated containers and the host editor

Previously, IDE integration did not work when the CLI ran inside a container sandbox while the editor ran on the host computer. The editor extension accepted only host-local connections and required an authentication token that the launcher did not pass into the container.

With the new approach, the host CLI launcher retains credentials and communicates with the editor. It relays messages through the container's command execution channel and an internal socket, a communication endpoint between programs. The connection uses standard input and output rather than networking. It is designed to work even in gVisor environments that separately isolate container networking.

The relay operates for the duration of the sandbox session. If the editor extension disconnects, the CLI prompts users to enable the connection again. During the next connection initialization, the host locates and reconnects to the editor.

3. Continue editor work while the host validates paths

Users open a project in VS Code, run the Gemini CLI companion extension, and start the CLI in container mode from the editor's integrated terminal. The container image must include node, and the extension must be running when the sandbox starts.

Once connected, users can check the connection with /ide status and request edits to view diffs in the editor. The original verification procedure checks whether accepting or rejecting edits in the editor also passes the result to the CLI.

Developers can keep sharing open-file context and reviewing changes while isolating the runtime in a container. The host launcher handles communication relaying and access-boundary validation. It allows only permitted tool requests and paths within the working folder. Diff requests for files outside that folder are rejected before they reach the editor.

4. Support scope and verified environments

The changes apply to Docker and Podman execution paths. The developer's change proposal records testing on a Linux workstation with Docker 29.7, using both standard Docker execution and runsc, the gVisor runtime. Connections were verified with both a real VS Code window and a test program standing in for the editor.

LXC and Windows hosts are outside this implementation's scope. Older images may display the previous guidance when no relay connection is available. On the verification host, rootless Podman failed before CLI startup due to an existing user ID mapping issue involving host-to-container account mapping rules. That execution path was therefore verified only through unit tests, which check behavior in small units.

This version creates an entry point for passing model information to automation and a connection channel for continuing editor work while preserving container isolation.