Claude in SSMS — or ChatGPT/Codex — on your own AI account

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.

02Five ways to get Claude in SSMS (October 2026)

SQL Sage is one of five routes, and not always the right one. Each row below cites the public source it rests on and the date we read it; check the source before you decide, because all five change quickly.

SQL Sage is independent: it is not affiliated with Anthropic, Microsoft, GitHub or the makers of the other tools named here. If you want the assistant to work through a multi-step task on the server, agents in SSMS covers how that works and where it stops.

03Coming from Claude Code + MCP?

If you already run Claude Code in a terminal against SQL Server, you already have what SQL Sage needs: the same Claude Code sign-in. There is nothing to migrate and nothing to give up, because the two do different jobs.

• Keep the terminal for long agent sessions over a repository and scripts, where Claude Code's own file and shell tools are the point.
• Use SQL Sage beside the open query window, where the error is in Messages and the connection is already made. The panel shows the server, database and login it is using, explains the error from sys.messages on your instance, and every write goes through the confirmation gate before Run.
• One session, one set of tools. On the Claude channel SQL Sage starts Claude Code with its own database tools only: your MCP servers and Claude Code's file, shell and web tools stay in your terminal sessions, not in SSMS. The database is reached only through those authored tools, and result rows go to the AI only with your consent.
• One plan. Both draw on the same Claude plan, so they share its usage limits.

04How CLI sign-in actually works

Most AI add-ins ask you for an API key. On this path SQL Sage asks for no key, because it does not talk to Anthropic or OpenAI itself. 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.

05CLI sign-in vs BYOK vs Copilot BYOM vs an API-key add-in

Four 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.

06Claude 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 native tools (files, shell, web, agents) are blocked separately, on every turn, through a settings deny-list, so only SQL Sage's tools remain. 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 and native tools. Every Codex turn runs codex exec --sandbox read-only with approvals set to never, Codex's built-in shell disabled and web search disabled, so SQL Sage's own tools (SQL checked by the ScriptDom classifier, your confirmation, results consent) are the only tools Codex can use. Claude turns block Claude Code's native tools (files, shell, web, agents) on every turn; only SQL Sage's tools remain. Our SQL gate applies to everything that touches your database on both channels. Whether the Codex CLI dispatches MCP tool calls under the read-only sandbox in every version is still being verified, and Codex tool use stays labelled experimental.
• 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. Each picker lists what your own installation reports: on the Claude channel SQL Sage asks your local Claude Code which models it offers (a start-up handshake — no message is sent and no model is called); on the Codex channel it reads the model catalogue Codex itself keeps on your machine. The BYOK path lists models straight from the Anthropic API with your key. A small signed policy from us (below) is used to hide a model, mark the recommended default or name the minimum CLI version a model needs.
• 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.

07What 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 through the same CLI. 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 only after you agree to share results (until then values in the plan are masked).
• 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.

08The 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 and, from version 0.32.0, a KILL — 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.

09What 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. From version 0.27.0 it also replaces every database on the server, logins, client machine names and file paths inside the results of the tools the AI runs; earlier versions do not rewrite tool results. From version 0.35.1 it covers inline completions too: those names in the text around your cursor become placeholders, the suggestion gets the real names back on your computer, and nothing is sent when the server's names cannot be read. Table and column names and result values you choose to share are not masked, 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 check (version.json, which you can switch off with Check for updates), the signed model list, a licence check for paid licences carrying only the licence identifier — our server records the date of the last check, kept for 35 days, to count active installations — and one anonymous count when you click Download in the update banner. There is no analytics or tracking code in the product, and none of these requests carries your name, email, a device or installation identifier.

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.

10Proof 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 do not take the model's word: the checks get their numbers from SQL we wrote and reviewed, run on your server. The “Same rows?” check and the audit log use no AI tokens; blast radius and on-call triage run inside an AI answer today (the model calls the tool), so they use your AI account like any other answer:

• 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, and switched off with Audit SQL. The queries SQL Sage runs or blocks are 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: it is tamper-evident, not tamper-proof. The chain has no secret key, so anyone who can write to your Windows profile can rebuild the chain, delete a whole day's file or drop the newest lines, and the chain will not show it; catching that would need an external signed checkpoint this local log deliberately does not add. It records the statement as it ran, with passwords and other secret values replaced with ? (the same rules as SQL Sage History; a statement whose secrets cannot be masked safely is recorded as withheld), the classification, and what happened (not logged: schema look-ups (table lists, column definitions), a few read-only diagnostics (wait stats, plan-cache top queries, active requests, deadlock history) and repository reads; the health check and Incident Mode are logged by name, without their SQL) — 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.

11New models appear without a new release

Model line-ups change faster than any extension ships, so the picker is filled from your own installation rather than from a list we ship: the Claude channel asks your local Claude Code which models it offers (a handshake with no message sent and no model called), and the Codex channel reads the model catalogue Codex itself keeps on your machine. When a new Claude or ChatGPT/Codex model reaches your CLI, it shows up in the picker without a SQL Sage release. Next to that, SQL Sage fetches a small signed policy from the same host as its update manifest — cached for 30 minutes, size-capped, abandoned after a three-second timeout, and ignored unless its signature checks out — which can hide a model, mark the recommended default or name the minimum CLI version a model needs. If your CLI cannot be asked, the panel falls back to the last list it read, then to the list built into your version: being offline costs you choice, not the product. One caveat stated plainly: the list is only as new as your CLI, so update Claude Code or Codex to see a model it does not know yet.

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.

12FAQ

13Requirements 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. For multi-step work on the server, see agents in SSMS.

AI usage not included: SQL Sage needs your own AI access (Claude Code on a paid Claude plan, a ChatGPT plan that includes the Codex CLI, or your own Anthropic API key). See pricing

Download (30-day trial, then Free)