Your own AI account in SSMS — Claude or ChatGPT/Codex, without an API key

01An add-in inside SSMS, not a website

SQL Sage installs into SQL Server Management Studio 22 on Windows and runs as part of the SSMS process on your own machine. It is not a web app, not an online SQL editor, and nothing about your database is proxied through our servers. The assistant lives in a dockable panel beside the query editor, and a connection bar at the top of that panel shows the server, database and login the current chat is using — at all times, not on hover. By default the chat follows whichever query window is active; when you are working across several servers you can pin it to one window so it keeps that connection while you move around. Either way an answer is grounded in a known engine edition, version and database rather than in SQL Server in general.

The same panel talks to either provider. Picking Claude or OpenAI is a pair of tabs in the status bar, with the model dropdown beside them — not a different product, a different install, or a different licence — and your conversation history survives switching provider or model mid-session.

02How keyless sign-in actually works

Most AI add-ins ask you for an API key. SQL Sage asks for nothing, because it does not talk to Anthropic or OpenAI at all. It talks to the command-line tool already installed and signed in on your machine — claude (Claude Code) for the Claude channel, codex for the ChatGPT/Codex channel — and lets that tool carry the authentication it already holds.

Concretely, on the Claude channel SQL Sage launches the CLI in non-interactive mode with a streaming JSON transcript (claude -p --output-format stream-json --verbose --include-partial-messages) and writes the prompt to the process's standard input rather than onto the command line — a schema-heavy prompt for a large production database would otherwise exceed the Windows command-line limit. Tokens are streamed back as they arrive, which is why the answer appears word by word instead of after a pause.

The practical consequences are worth spelling out. Rotating or revoking access is done in your Claude or ChatGPT account and takes effect immediately, with nothing to clean up in SSMS. If your CLI session expires, SQL Sage does not silently fall back to some other credential — the channel simply reports itself unavailable until you sign in again. And because the inference runs on your own subscription, usage is billed by your provider under the terms you already accepted: SQL Sage is not an intermediary for AI inference, does not meter it, and does not resell access to models.

03Keyless vs BYOK vs an API-key add-in

Three arrangements are easy to confuse, so here is what each one actually means for you.

BYOK exists as an escape hatch for people who cannot or will not install a CLI — for instance on a locked-down workstation. Note the asymmetry honestly: BYOK is implemented for Anthropic only. There is no OpenAI API-key path, so reaching ChatGPT or Codex means going through the Codex CLI. If your organisation forbids both a CLI and an outbound API key, no configuration of SQL Sage will help, and it is better to know that before you install.

04Claude or ChatGPT/Codex — what actually differs

For everyday T-SQL work — explaining an error, reading an execution plan, rewriting a query — both channels get the same tools, the same schema context and the same safety gate, because all of that lives in SQL Sage rather than in the model. What differs is a small number of concrete engineering facts, not marketing positioning:

• How the database tools are wired in. SQL Sage runs its own tool server on 127.0.0.1, guarded by a per-session bearer token, and speaks the Model Context Protocol to it. Claude Code is pointed at that server with --strict-mcp-config plus an explicit allowlist naming only our tools — so no MCP server other than ours is loaded in that session. That is a statement about MCP specifically, not about the CLI as a whole: Claude Code's own file and shell tools are governed separately, and are walled off outright only when you connect a repository. The Codex CLI has no equivalent flag and normally loads MCP servers from its own config.toml, so SQL Sage injects ours, and only ours, as a command-line override. Either way the model reaches your database through exactly one authored, gated channel and never over a connection of its own.
• Sandboxing is where the channels genuinely diverge — and Codex comes off worse. Plain chat on the Codex channel runs codex exec inside a read-only sandbox. But dispatching MCP tool calls headlessly requires relaxing that sandbox, so when the SQL tools are enabled on the Codex channel the CLI process is no longer sandboxed, and Codex's own shell tool is not behind our chokepoint. Our SQL gate still applies to everything that touches your database. We say this in the product too, where the provider picker labels Codex tool use experimental and names Claude the lower-risk default. If you want the tighter of the two arrangements, use Claude.
• Streaming granularity. The Claude channel streams token by token, so text appears as it is generated. The Codex channel delivers a completed message per step, so the answer arrives in blocks. Same content, different rhythm.
• Model discovery. Neither CLI has a command that lists the models it can run, so both pickers are filled from our hosted catalogue (below). Only the BYOK path can enumerate models live, straight from the Anthropic API.
• Connecting a repository is a Claude-only preview. Letting the assistant reason about your application source next to the database depends on being able to switch the CLI's native file, shell and search tools off and serve a secret-screened view through our own read and search tools instead — nothing is copied, and secret files are withheld or redacted at read time. That fence is expressible on the Claude channel. The Codex sandbox constrains what the process may do rather than which files it may read, so rather than risk exposing unrelated credentials on your disk we simply do not offer repository access there.
• BYOK. Anthropic only, as above.

Everything else is symmetric: both channels call the same tools, obey the same safety gate, write to the same audit log, and keep your conversation when you switch between them mid-session.

05What it does with your SQL

The assistant reasons about the server in front of you, because it can measure it. It has 26 authored tools — deterministic queries we wrote and reviewed, not SQL the model improvises — covering the catalogue, Query Store, the plan cache, wait and index statistics, live requests, deadlock history, permissions and backups. The model chooses which one to call and interprets what comes back; it does not invent the numbers.

• Explain errors from the real catalogue. Ask about Msg 8134 and the actual text and severity are read from sys.messages on your instance before anything is explained — no hallucinated error strings.
• Explain, fix, optimize, document. Select T-SQL in a query window and right-click → Ask SQL Sage ▸ Explain selection / Fix selection / Optimize selection / Document selection, or press Ctrl+Alt+Shift+E/F/O/D. The chat opens with your selection already attached; the same actions are on the Tools menu. Slash commands (/explain, /optimize, /fix, /doc, /querystore, /format, /help) act on the attached query, and /format costs zero tokens because it runs locally.
• Inline completions, keyless too. Schema-aware suggestions plus AI completions on Alt+. — on the CLI channels the AI completion is deliberately manual, so nothing is sent while you type unless you ask for it.
• “Why is it slow?” answered with numbers. Wait statistics, the live blocking chain, deadlock history, Query Store regressions and forced plans, and the execution plan — estimated and actual.
• Health and risk in one shot. Backups and per-database RPO risk, failed Agent jobs, fragmentation, stale statistics, memory pressure, risky database options, missing-index recommendations cross-checked against the indexes you already have, and a permissions audit with nested roles expanded.

Every SQL block the assistant writes carries a classification badge — READ, WRITE, DDL, or SQL? for a statement that cannot be proven safe — and a one-click toolbar: Copy · Insert · New query · Run · Format · Prove ≡. Press Run on anything that is not a plain read and the confirmation dialog names the class again in its own words: WRITE, DDL, or UNSAFE for the unprovable case. Insert is deliberately not Run: putting text in your editor and executing it against a database are two different buttons.

06The safety gate: classify first, then decide

Nothing an AI writes reaches your server on trust. Before execution, every batch is split on GO the way SSMS splits it and parsed into an abstract syntax tree by ScriptDom — Microsoft's own T-SQL parser, the TSql180Parser — then classified as Read, Write, DDL or Unknown. A batch takes the worst class any statement in it earns. The classification is deterministic and escalates on exactly the cases that catch people out:

• Read runs. A genuine SELECT executes read-only on a fresh connection — so no session options, temp tables or open transactions from your query window leak into it — capped by default at 200 rows and a 30-second timeout, with a lock timeout so a preview cannot sit on a blocked resource.
• Write and DDL stop. A confirmation dialog shows the exact SQL, in full, before anything executes — every time, with no “don't ask again”. SELECT … INTO counts as a write because it creates and populates a table; NEXT VALUE FOR counts because it advances a sequence.
• Unknown is treated as dangerous, not as probably fine. If the batch will not parse, or it hides behind EXEC / sp_executesql, or it is something the classifier does not positively recognise as safe, it is classed Unknown and needs the same confirmation. The default answer to “I can't prove this is a read” is no.
• Remediation is a script, not an action. Rebuilds, UPDATE STATISTICS, CREATE INDEX, ALTER DATABASE — all handed to you to review and run yourself. The assistant never applies them silently.

There is one more gate on your side of the keyboard: when you press F5 on something genuinely destructive — a DELETE or UPDATE with no WHERE, a DROP, a TRUNCATE — SQL Sage asks first, using the same parser.

The parser is the chokepoint, and that matters more than any instruction in a prompt could: a model cannot talk its way past a gate that is not made of words.

07What leaves your machine — and what does not

The assistant needs enough context to be useful, which is your query text and the shape of your schema. It does not need your data, so by default it never sees it.

• Sent to the provider: your query text, schema metadata (table, column and index names), the server and database name plus engine edition, version and compatibility level, the diagnostic output the tools collect, and execution plans — distilled to the operators and warnings that matter rather than dumped as raw XML.
• Not sent: rows from your result grids. This is double-gated. An Include results switch is off by default, and even with it on the first send in a session asks for explicit consent, showing the row and column count and stating plainly that the data will leave your machine. That consent is tied to the specific server, database and provider — change any of them and you are asked again.
• An honest limit on masking. The Mask names option replaces the server and database names in the context SQL Sage composes, and omits the login. It does not rewrite values inside every tool result, so treat it as reducing exposure of your topology, not as anonymisation.
• Ours to see: nothing about your queries, schema or results. The extension's only calls home are the update manifest, the model catalogue, a licence check carrying an opaque licence identifier, and an anonymous counter when a download link is clicked. There is no telemetry or usage reporting in the product.

Because inference runs on your own account, your direct relationship with Anthropic or OpenAI governs how that context is handled; we are not a sub-processor for it. The Privacy Policy spells this out field by field, and the sub-processor list names everyone we do use.

08Proof and accountability, not just answers

Confidence is cheap and a plausible answer about production is dangerous. The parts of SQL Sage that exist to prove things run deterministically on the server and cost no AI tokens:

• Blast radius before ALTER or DROP. Read from the system catalogues: dependent views, procedures, functions, triggers and constraints, inbound foreign keys, rows at risk, and the object's own indexes. Stated limit — static analysis cannot see dynamic SQL or cross-database references, and the report says so rather than implying completeness.
• “Same rows?” checked, not asserted. When a rewrite is proposed, one click compares old and new with an order-independent, duplicate-aware server-side multiset fingerprint plus the logical-reads delta, and returns EQUIVALENT, DIFFERENT or UNDECIDABLE. It runs read-only inside a rolled-back transaction, and it admits when a query is nondeterministic and cannot be proven. It verifies the data you have now — not a proof for all possible data.
• A local audit log you can hand to an auditor. On by default. Every AI action performed or blocked is appended to a daily JSONL log under %LOCALAPPDATA%\SqlSage\audit\, hash-chained: each line stores the SHA-256 of the previous hash plus the canonical form of the event, so a deleted or edited entry breaks the chain and is detectable rather than invisible. The limit, stated as plainly as the rest: that holds for entries that remain in the file — like any bare append-only chain it cannot prove on its own that the newest lines were not dropped from the end, which would need an external signed checkpoint this local log deliberately does not add. It records the full statement, the classification, and what happened — local-only, with no network path out of the audit code at all — and exports as an evidence pack in Markdown and JSON with the chain's integrity verdict attached.
• On-call triage that cites its numbers. One click reads live DMVs for the blocking chain, top waits with each one's share, and the most expensive in-flight queries — read-only, edition-aware across box SQL Server and Azure SQL Database, and reading server state only, never table data.

09New models appear without a new release

Model line-ups change faster than any extension ships. SQL Sage reads its model list from a small hosted catalogue served from the same CDN as its update manifest — refreshed at most once every 30 minutes, size-capped, and abandoned after a three-second timeout — so when a new Claude or ChatGPT/Codex model becomes available it shows up in the picker without you installing anything. If the catalogue cannot be reached, the panel falls back to the list built into your version: being offline costs you choice, not the product. One caveat stated plainly: the catalogue governs what the picker offers, not what the CLI on your machine will accept, so a brand-new model also needs a CLI recent enough to run it.

One hardening detail, since it is the kind of thing that gets skipped: a model identifier is eventually passed as an argument to a CLI that may be launched through a .cmd shim, where argument quoting does not neutralise shell metacharacters. Every identifier is therefore validated against a strict format rule before it can reach the command line — alphanumerics, dots, underscores and hyphens only, 64 characters at most, no whitespace and no shell metacharacter — and a malformed string is replaced with a known-good alias rather than passed on. Be precise about what that buys: a well-formed name for a model that does not exist still reaches the CLI, which rejects it. What cannot get through is an injected command.

10Requirements and first run

• SQL Server Management Studio 22 on Windows (x64 or Arm64), with .NET Framework 4.8 or newer. SSMS 22 is the only supported host — the installer checks for it and stops if it is not there.
• Claude Code or the Codex CLI, installed and signed in with your Claude or ChatGPT account — that is the channel to the AI. Install links are in the panel. (Advanced alternative: your own Anthropic API key.)
• Administrator rights for the install, because it writes to Program Files — standard for SSMS extensions.
• An active connection in a query window, so the assistant knows which server and database it is talking about.

1. Install SQL Sage and reopen SSMS — the panel appears, or open it from View → Other Windows → SQL Sage.
2. In the status bar pick your provider. Sign in with Claude finishes in the console window that opens; then click Refresh. Sign in with OpenAI goes through the Codex CLI.
3. Choose a model, then select some T-SQL and press Ctrl+Alt+Shift+E.

Every install starts a 30-day free trial with all features, no credit card and no account, and licence checks fail safe — there is a 14-day offline grace period, so a flaky network or a week on a plane will not lock you out. The step-by-step walkthrough lives in the documentation; if you are weighing this against GitHub Copilot in SSMS or other add-ins, the side-by-side comparison is the honest version, with sources.

Download SQL Sage