Claude and ChatGPT in DBeaver without an API key — how it works and where it stops

How to use Claude (Claude Code) or ChatGPT/Codex in DBeaver without an API key: sign in through your own CLI, schema-aware SQL, writes held at a gate.

Author: Łukasz Żochowski

  • #sql
  • #dbeaver
  • #ai
  • #security

Disclosure: I work on SQL Sage for DBeaver, the tool covered in the second half of this post. The first half is a set of criteria you can use to judge any AI plugin for DBeaver, mine included.

Search for “claude dbeaver” or “chatgpt dbeaver” and you usually land on the same recipe: generate an API key with the model provider, paste it into the settings, done. It works. But the recipe smuggles in three decisions nobody wrote down:

  1. Who guards the secret? An API key is a password to your account with the model provider — without a second factor and usually without an expiry date.
  2. What are you paying for? A key bills per token, separately from the Claude or ChatGPT subscription you most likely already have.
  3. What can the assistant do to the database? DBeaver holds connections to many engines at once, production ones included. An assistant that runs SQL on its own needs a brake.

Below, in order: why the key is a liability, what the keyless approach looks like, what an assistant in DBeaver should actually do, and how to put it together.

1. An API key is a secret you start storing

An API key pasted into a tool stops being a “setting”. It becomes a secret that now lives in a config file on disk, in the backups of that file, sometimes in a settings export you send a colleague. One screen-share with the preferences window open is enough.

Then there is the second bill. A key is metered per token, regardless of the fact that you already use a Claude or ChatGPT plan in the terminal. The same person pays twice for the same model, through a different channel.

I made the longer argument in API keys are a liability: the keyless security case. The rule of thumb is enough here: if you have no specific reason to manage a key, do not.

2. How keyless works: sign in through your own CLI

The alternative is a plugin that does not talk to the model itself but drives a command-line tool you are already signed in to:

  • Claude — through claude, the Claude Code CLI, signed in with your Claude account.
  • ChatGPT/Codex — through codex, signed in with your ChatGPT account.

The sign-in stays in the CLI. The plugin never receives a key or a token — at most it asks the CLI whether the session is signed in, then hands it your question and reads the answer. Usage counts against the plan you already have, under the provider’s terms.

You can check the sign-in state yourself with the same commands such a plugin uses:

where claude                 # is the CLI on PATH?
claude auth status --json    # expect {"loggedIn":true,...}
codex login status           # the same for Codex

One question worth asking any “keyless” plugin: does it really store no credentials anywhere? If its settings have a field for a token, that is not keyless — it is a key under another name.

3. What an AI assistant in DBeaver should do

Sign-in is only half of it. In DBeaver you work with a specific connection on a specific engine, so a good assistant has to account for that.

Write SQL from the schema, not from guesses

A model that cannot see your schema invents table and column names that sound plausible. The assistant should read the active connection’s metadata — tables, columns, keys, indexes — and write SQL in that connection’s dialect. In DBeaver this matters twice over, because the same question is written one way in PostgreSQL and another in SQL Server or Oracle (I listed the differences in the five-engine comparison).

Read-only by default, writes held at a gate

The pattern worth enforcing whatever tool you use:

  • SELECT may run immediately.
  • Anything that is not a proven read — INSERT, UPDATE, DELETE, DDL, and also a statement the parser cannot make sense of — stops and waits for your confirmation, with the exact SQL shown.
  • Several statements at once are a red flag. SELECT 1; DROP TABLE t must not pass as a “read” just because it starts with SELECT.

Send schema and SQL, not rows

To write a query the model needs structure, not data. A sensible default: the model gets the SQL text and schema metadata, and from an executed read — column names and the row count, without values. Showing values to the model should be a deliberate opt-in. More on this in Does AI see your data when it writes SQL?

4. Where SQL Sage for DBeaver fits

SQL Sage for DBeaver is a plugin for DBeaver 26.x (Community or PRO) built exactly around those criteria:

  • No API key — it signs in through the claude or codex CLI you already have signed in. The plugin never asks for, stores or transmits a key; it only checks the sign-in status with the CLI’s own command. You switch between Claude and ChatGPT/Codex in the same panel.
  • Schema-aware SQL — it answers for the active connection, grounds its SQL in the live schema (tables, columns, keys, indexes) and writes in that connection’s dialect: PostgreSQL, MySQL/MariaDB, Oracle, SQL Server and SQLite.
  • Read-only by default, with a gate — every statement passes one classifier before it reaches the database. A plain SELECT runs; anything else waits for a confirmation dialog showing the exact SQL, and several statements in one call are refused. You can mark a connection Read-only or No execution, and there is a global kill-switch for AI-initiated statements.
  • Schema and SQL, not rows — result values are withheld from the model by default. If you turn sharing on (/share on or a Preferences checkbox), it stays on until you turn it off. Every classifier decision and every executed statement goes to a local audit log on your own disk.

The page Claude and ChatGPT in DBeaver, no API key walks through the sign-in mechanism in detail, and the SQL Sage for DBeaver product page sums up which databases it works with and what reaches the model.

5. Setup at a glance

The full guide, with requirements and the usual failure modes, is in the documentation. In short:

  1. Install the plugin in DBeaver: Help → Install New Software… → Add… with the update site https://sqlsagedbeaver.lumasoft.org/updatesite, then restart.
  2. Sign in to the CLI once: run claude and use /login, or run codex login. If you already use either in the terminal, this step is done.
  3. Open the chat panel with Ctrl+Alt+A. The status bar shows which provider you are signed in to.
  4. Ask in plain English — the assistant inspects the active connection’s schema and writes SQL in its dialect.

Two traps people hit most often:

  • “Not signed in” although the CLI works in your terminal. DBeaver launched from an icon does not inherit your shell’s PATH. Quickest diagnosis: start DBeaver from the same terminal where claude auth status --json returns loggedIn: true. If it works then, the cause is PATH — add the CLI’s directory to your user PATH in Windows settings, then sign out and back in.
  • DBeaver under C:\Program Files\. Installing a plugin needs write access to the DBeaver directory, which a normal account does not have there. The documentation lists three ways out.

6. Honest limits

  • Windows only. Linux and macOS are neither supported nor tested: the build targets a single environment, and the interactive CLI sign-in only opens a console window on Windows.
  • You need the CLI. Without claude or codex installed and signed in, the plugin has nothing to talk to the model through. That is the price of keyless: the secret stays with you, and so does the sign-in tool.
  • An engine-enforced read-only transaction covers PostgreSQL and MySQL/MariaDB. On the other engines you are protected by the classifier and the confirmation gate, not by a database transaction — the documentation spells out the limits of the safety model.

If you also work in SSMS

I described the same approach — sign in with your own account, read-only by default, schema and SQL to the model — for SQL Server Management Studio in How to use Claude or ChatGPT inside SSMS without an API key. The criteria are the same; only the editor changes.

The main takeaway is not about any particular plugin, though: before you connect AI to DBeaver, check where the secret lives, what reaches the model, and what stops a write. If a tool cannot answer those three questions plainly, that is your answer.

SQL Sage is made by LumaSoft (LUMA sp. z o.o.). Not affiliated with Anthropic, OpenAI, or DBeaver.

← Back to the blog