HomeClaude & ChatGPT in DBeaver

Keyless · no API key

Claude — and ChatGPT/Codex — in DBeaver, on the account you already have

SqlSage puts an AI SQL assistant inside DBeaver 26.x and signs in through the claude or codex CLI you already have. No API key, no separate AI bill, no token for SqlSage to keep. Usage counts against your existing Claude or ChatGPT plan.

What “keyless” actually means

Most AI tools ask you to paste a provider API key and then bill you per token on top of whatever you already pay. SqlSage does neither. It reuses the login that already lives in your claude or codex CLI — the same subscription you use in the terminal. SqlSage never asks for, stores or transmits an API key, and it never handles your provider tokens.

Concretely: to check whether you are signed in, SqlSage runs the CLI’s own status command as a short-lived process (claude auth status --json, or codex login status). That is the whole mechanism. Authentication stays inside the CLI where you control it; SqlSage only asks the CLI “is this session signed in?” and drives it to answer your questions.

No key to paste

Nothing to generate in a provider console, nothing to rotate, nothing that can leak from a preferences file.

No second bill

AI usage counts against the Claude or ChatGPT/Codex plan you already have, under that provider’s terms. SqlSage adds no per-token AI fee.

Zero token custody

SqlSage never sees, stores or transmits a credential. Sign-in lives in the CLI; the AI traffic is the CLI’s, not ours.

How it works, end to end

  1. Install the plugin from the p2 update site into DBeaver 26.x (Community or PRO). No DBeaver licence is required.
  2. Sign in to the CLI once — run claude and use /login, or codex login. If you already use either in the terminal, you are done.
  3. Open the panel — Window → Show View → SqlSage → SqlSage Chat (Ctrl+Alt+A). The status bar shows which provider you are signed into.
  4. Ask in plain English. SqlSage inspects the live schema of your active connection and writes SQL in that connection’s dialect.
  5. It runs a read for you — a cleared SELECT executes on a dedicated session and returns rows; anything that writes stops for your confirmation.
“Not signed in” even though the CLI works in your terminal? An app launched from an icon does not inherit your shell’s PATH. Put the CLI’s directory on your user PATH and sign out and back in — full detail in the documentation.

Both providers, one panel

Cover Claude and ChatGPT/Codex from the same place: switch provider in the status bar and SqlSage re-checks sign-in for the one you picked. There is no separate “Claude edition” and “ChatGPT edition” — it is one plugin that speaks to whichever account you are logged into.

The model picker is editable: it suggests the aliases each CLI understands and accepts anything else you type, and blank means the CLI’s own default — so a model your account gains tomorrow needs no plugin update. The composed prompt goes to the CLI on standard input, never the command line, so it never shows up in a process list.

It answers for your connection — on any of five engines

SqlSage always answers for one active connection, and the panel names which. Switch connections and the chat follows. The assistant grounds its SQL in the live schema — tables, columns, keys and indexes — instead of guessing identifiers.

The same keyless assistant works across the relational engines DBeaver connects to — PostgreSQL, MySQL/MariaDB, Oracle, SQL Server and SQLite — and writes SQL in each connection’s own dialect. If breadth across engines is what you care about, the companion page goes deeper: one copilot, five database engines →

Read-only by default, writes gated

Every statement the model proposes passes one classifier chokepoint before anything reaches your database. A plain SELECT runs; anything not proven to be a read — including writes, DDL and anything the parser cannot make sense of — is treated as a write and held for an explicit confirmation dialog showing the exact SQL. A batch is split and the worst verdict wins, so SELECT 1; DROP TABLE t is a write.

You also get controls that sit outside the model’s reach: mark a connection Read-only (writes hard-refused) or No execution, and a global kill-switch that freezes every AI-initiated statement instantly. The honest limits — no driver-level read-only session, no query timeout — are documented in full on the safety model page.

What leaves your machine

Only your SQL and schema metadata (table and column names and types) are sent to the model — never row data. When a read executes, the default is to return column names and the row count only, with values withheld. You can opt in to sharing result values with /share on or a Preferences checkbox; that opt-in is off by default and stays in effect until you turn it off.

Every classification decision and executed statement is appended to a local, hash-chained audit log on your own disk — nothing uploads it. And because SqlSage drives your local CLI, the AI traffic is the CLI’s conversation with Anthropic or OpenAI under your account, with credentials SqlSage never touches.

Keep reading