dbgorilla-cli

dbgorilla

The DBGorilla CLI. Sign in to a DBGorilla deployment and connect Claude Code as an MCP client in three commands.

Install

On-prem / air-gapped (recommended for enterprise)

Your DBGorilla deployment serves the install script at its own URL. The script downloads the binary from the same host and configures the CLI for your deployment automatically.

curl -fsSL https://<your-deployment>/install.sh | sh

Homebrew

brew install dbgorilla/tap/dbg
dbg --api-url https://<your-deployment> login

The first dbg login persists the API URL (and --insecure if you pass it) to ~/.config/dbgorilla/cli.toml (or $XDG_CONFIG_HOME/dbgorilla/cli.toml), so every subsequent command runs without flags.

Manual

Download a binary from the Releases page and put it on your PATH.

Quick start

dbg login          # sign in (browser-based SSO or username/password)
dbg setup-ide      # configure every detected MCP client (Claude Code, Cursor, VS Code, ...)
dbg doctor         # verify everything works

That's it. Restart your IDE/agent and DBGorilla is wired up.

Supported MCP clients

dbg setup-ide auto-detects every supported client installed on your machine and configures each one. Pass --client <slug> to target a specific tool, or --list-clients to see what's supported and which are detected.

Useful flags:

dbg setup-ide --list-clients              # what's supported, what's detected
dbg setup-ide --client cursor             # target one
dbg setup-ide --client cursor,vscode      # target several
dbg setup-ide --scope project             # override the per-client default scope
dbg setup-ide --dry-run                   # show what would be written
dbg setup-ide --print-config --client X   # print the entry to paste manually

The merge is safe: existing MCP servers and unrelated config keys are preserved, every write is preceded by a <path>.backup.<timestamp>, and JSONC files (with // comments) are refused rather than overwritten.

Note on the first call: if your CLI hasn't been pre-configured (no install-script, no MDM-deployed system config), pass --api-url https://<your-deployment> once on login. The CLI persists it on success and no subsequent command needs the flag again. Same for --insecure if you're on a private CA.

Commands

Centralized Claude allowlist

If your org uses a managed Claude allowlist (Team / Enterprise tier on app.claude.com), dbg setup-ide may be blocked by policy. Run:

dbg setup-ide --print-admin-allowlist

...and send the output to whoever manages your Claude admin console. Once they allowlist dbg, re-run dbg setup-ide.

TLS with a private CA (on-prem deployments)

If your DBGorilla deployment uses an internal CA — common for on-prem — TLS verification fails by default in two places that matter, and each needs a separate fix:

1. The CLI itself

dbgorilla reads the system trust store. Recommended:

• Have your IT team install the internal CA on each developer's machine (via MDM payload, security add-trusted-cert on macOS, or update-ca-certificates on Linux). Standard system-wide trust; nothing to configure in the CLI.

As a stopgap until the CA is trusted system-wide, pass --insecure (-k) once on login:

dbg --api-url https://<your-deployment> --insecure login

That persists insecure = true to ~/.config/dbgorilla/cli.toml, so subsequent commands run insecure automatically. To turn it off later (after IT installs the CA), run:

dbg config unset insecure

Skipping TLS verification trains bad habits — it's a stopgap, not a deployment strategy.

2. Node-based MCP clients (Claude Code, opencode)

Several supported clients are Node applications. Node maintains its own bundled CA list and does not read the macOS Keychain or /etc/ssl/certs by default. Even after IT trusts the CA at the OS level, these clients may still reject the MCP server's certificate.

Point Node at the CA bundle:

# Add to ~/.zshrc, ~/.bashrc, or wherever your IDE/agent's environment comes from:
export NODE_EXTRA_CA_CERTS=/path/to/your-internal-ca.pem

NODE_EXTRA_CA_CERTS adds the named CA to Node's trust store without disabling verification for anything else. IT can deploy the CA file to a fixed path (e.g. /usr/local/share/ca-certificates/acme-internal.pem) via MDM and push the env var via a shell snippet.

dbg setup-ide detects when you're running insecure and reminds you about NODE_EXTRA_CA_CERTS at the end of setup — that's the moment your IDE is about to try connecting and will fail without it.

What to avoid

NODE_TLS_REJECT_UNAUTHORIZED=0 disables certificate verification for every HTTPS connection Claude Code makes — including the Anthropic API, npm, and every other MCP server. Anyone on the network can impersonate any server. Don't use it. NODE_EXTRA_CA_CERTS is the right knob.

Configuration

Two persisted settings: api-url and insecure. Both follow the same priority chain (highest first):

1. Command-line flag (--api-url, --insecure / --insecure=false)
2. Environment variable (DBGORILLA_API_URL; there is no DBGORILLA_INSECURE env var — persist via dbg config set insecure true or pass --insecure on each call)
3. $XDG_CONFIG_HOME/dbgorilla/cli.toml (per-user; defaults to ~/.config/dbgorilla/cli.toml; written by dbg login and dbg config set)
4. /etc/dbgorilla/cli.toml (or /Library/Application Support/dbgorilla/cli.toml on macOS, C:\ProgramData\dbgorilla\cli.toml on Windows) — IT-deployed via MDM, read-only from the CLI

If nothing is configured, dbgorilla exits with an actionable error pointing at the layers above.

dbg config get <key> shows which layer won the lookup.

Persisted on successful login

dbg login writes both api-url (always) and insecure (when --insecure was explicitly passed) into the user config. This is the "I logged in once with the flags, now everything just works" pattern. Saved values are visible in ~/.config/dbgorilla/cli.toml.

Overriding persisted state

• --api-url https://other — one-shot override; doesn't change config.
• --insecure=false on dbg login — turns off any persisted insecure = true.
• dbg config unset insecure — clears insecure without re-logging in.

Compatibility

Requires a DBGorilla deployment that exposes the Keycloak device-flow auth-config endpoint and the MCP API-key endpoints. If you're unsure whether your deployment qualifies, contact your DBGorilla administrator.

Building from source

For contributors:

git clone https://github.com/dbgorilla/dbgorilla-cli.git
cd dbgorilla-cli
go build -o dbg .

Requires the Go version declared in go.mod (see the badge at the top of this README for the live value). Released binaries are produced from this same source by goreleaser on every v*.*.* tag — the ./dbg you build locally behaves identically.

Cross-compile for another platform:

GOOS=darwin GOARCH=arm64 go build -o dbg-darwin-arm64 .
GOOS=darwin GOARCH=amd64 go build -o dbg-darwin-amd64 .
GOOS=linux  GOARCH=amd64 go build -o dbg-linux-amd64 .
GOOS=linux  GOARCH=arm64 go build -o dbg-linux-arm64 .

Feedback

Open an issue for bug reports or feature requests. Please include the output of dbg doctor (redacting any sensitive values) and your platform.

Known limitations

• The one-paste install path (curl https://<your-deployment>/install.sh | sh) requires your DBGorilla deployment to serve a matching install script and binaries. Until then, install via Homebrew or download a binary from Releases.
• A handful of MCP-capable tools are out of scope today because they don't expose a remote-HTTP MCP path through their config files: Codex CLI / omx (HTTP support documented but not yet functional), Aider (no MCP client config), Zed (config-file MCP is stdio-only), and Antigravity (no public docs). They'll be added once their config surface supports HTTP MCP with a Bearer header.

License

MIT