If you're coming from Gemini CLI, this guide highlights the key differences and shows you how to get productive quickly.
| Gemini CLI | LLxprt Code | Notes |
|---|---|---|
gemini |
llxprt |
CLI binary name |
@resume |
/continue |
Resume a previous session |
% (shell escape) |
! or shell tool |
Run shell commands |
/auth (Google-only) |
/auth |
Multiple providers: anthropic, codex |
Gemini CLI uses environment variables (GEMINI_API_KEY) or OAuth for Google only. LLxprt Code supports multiple providers and stores credentials in your OS keyring, which is more secure than environment variables.
Why keyring over env vars? Environment variables can leak through process listings (ps), child process inheritance, shell history, and CI logs. The OS keyring is encrypted at rest and requires authentication to access.
Save a key to the OS keyring from inside a session:
/key save xai-prod your-api-key-value
Then use it in future sessions — the key never appears in shell history:
llxprt --provider xai --key-name xai-prodOr use a keyfile for CI/automation:
llxprt --provider xai --keyfile ~/.llxprt/keys/.xai_keyFor OAuth providers (Anthropic, Codex), enable any of them:
/auth anthropic enable
/auth codex enable
With /auth <provider> enable, authentication is lazy — a browser opens automatically when you make your first request. Use /auth <provider> login to open the browser immediately.
Gemini is now API-key-only. Google removed the free consumer "Login with Google" access for Gemini CLI in mid-2026. Use a Gemini API key (
GEMINI_API_KEYor/keyfile) or Vertex AI credentials instead.
See Authentication for full details.
Instead of setting provider/model/parameters every session, save a profile:
/provider xai
/model grok-4
/set reasoning.enabled true
/profile save grok
/profile set-default grok
Load at startup:
llxprt --profile-load grokThis is the recommended way to manage configuration. See Profiles.
LLxprt Code supports running in sandboxed containers (Docker/Podman) for safety. You can even create sandbox-specific profiles that automatically run in a container:
# Run sandboxed
llxprt --sandbox dockerCreate a sandbox profile from inside a session:
/set sandbox docker
/set sandbox-engine podman
/profile save sandboxed
See Sandboxing.
If you're migrating from Gemini CLI, you may want to import existing configuration. LLxprt Code stores its files in OS-standard directories rather than ~/.llxprt, so don't symlink into ~/.llxprt — copy your Gemini CLI files into LLxprt's config directory once instead.
# Resolve LLxprt's config directory for your platform (see Application Directories)
# Example on Linux: CONFIG_DIR="${LLXPRT_CONFIG_HOME:-$HOME/.config/llxprt-code}"
# Import your global memory/context file
cp ~/.gemini/GEMINI.md "$CONFIG_DIR/LLXPRT.md"
# Import settings (review first — not 100% compatible; see caveats below)
cp ~/.gemini/settings.json "$CONFIG_DIR/settings.json"After importing, review the settings file: LLxprt Code has multi-provider auth, profiles, and settings that Gemini CLI doesn't, so some keys may be ignored or need adjustment.
- MCP server configurations (if paths are absolute)
- Context/memory files (GEMINI.md → LLXPRT.md)
.envfiles (though keyring is preferred over env vars)
- Authentication (different auth systems)
- Model configuration (profiles vs single default)
- Provider-specific settings
Recommended approach: Start fresh rather than symlinking everything.
- Install LLxprt Code and run it without symlinks
- Set up auth:
/auth <provider> enablefor OAuth providers, or--key-namefor API keys - Configure your preferred setup and save a profile
- Optionally symlink your LLXPRT.md / GEMINI.md context file