There is no SQL console in Opbox, and there will not be one. A console that runs arbitrary SQL would be a second way into the data that sits beside the kernel rather than behind it, and that is exactly the thing the system is built to prevent. The verb dispatch is the only door to the store: every read and every write passes through it, permission-checked, scope-checked, and audited. A raw-SQL surface would have to either bypass that door (an ungoverned channel over the whole workspace in plaintext) or rebuild it (a SQL parser and rewriter, a second trust boundary and a fresh attack surface). Both were considered and both were rejected. The query needs that a console would have served are met instead by governed verbs that already exist.
What it does
It does not exist, and that is the design. Opbox carries one trust boundary: the kernel verb. Standing up a SQL console would mean accepting SQL text and executing it against the database, which can only happen by going around the verb gate or by duplicating it. Going around it would read and write the workspace’s entire plaintext outside the per-verb tiering and the read fences that keep one matter, one tenant, and one sealed column from leaking into another. Duplicating it would put a parser and a rewriter in the path: a second dispatch layer to secure, audit, and keep honest forever. The decision was to have neither. This is a permanent posture, not a feature waiting in a backlog.
Every read is already a verb. The things you would reach for a SQL console to do - look something up, pull a list, follow a trail, check a figure - are governed reads in the kernel. You find anything across matters, documents, and parties through search. You inspect and prove the permanent record through the audit feed. You read structured data through the data-plane table and row reads. Each of those runs through the same front door as every write, so a read is permission-checked and scoped to what the caller may actually see, and it cannot quietly step outside the fences a raw query would ignore.
Aggregates and reporting are a verb question, not a SQL question. A dashboard figure or a roll-up is a real need, and it is met the same way every other capability is: by a named read verb with a defined shape and a tier, not by hand-written SQL. When a new aggregate is genuinely required, it is added as one consolidated read verb that the front door governs like any other, so the number on a board carries the same scope checks and the same audit trail as the data it summarises.
The agent reads through the same verbs you do. When you want an answer that would once have been a query, you can ask the assistant. It calls the same governed reads - search, audit, the data-plane reads - under its own bounded permissions, and it cannot see anything you could not. There is no privileged query path the agent holds and you do not.
Host-level database access is an operations matter, outside the product. An operator with infrastructure credentials running psql on the box is a separate thing entirely: it lives at the host, under the people who run the server, not inside the product surface any user reaches. The product does not expose it, wrap it, or formalise it into a feature. That line is deliberate, and it is where raw database access stays.
How you use it
Find something across the workspace. Use search to look across matters, documents, and parties for whatever you are after. The results are scoped to what you are allowed to see, so search answers the “where is the thing” question a query would have, without opening the whole store.
Read structured data directly. When you need rows out of a table - a register, a list, a set of records - read the table and its rows through the data-plane verbs. You get the data the table holds, fenced to the matters and the tenant you may reach, rather than an open window onto the database.
Inspect and prove the record. When you need to know who did what, when, and on what basis, query and follow the audit feed and verify the chain is intact. The audit verbs are how you interrogate history, and unlike a raw query against a log table, they keep the proof of the record’s own integrity in the answer.
Ask the assistant for the answer. For a question you would have written SQL to settle, ask in chat. The agent gathers the answer through the same governed reads, within its own permissions, and shows its working.
For host operations, go to the operator, not the product. Genuine database administration - a migration, a recovery, a diagnostic that only host credentials can run - is handled at the server by whoever operates the box. It is not something the product surfaces, and it should not be.
The kernel verbs behind it
There is no SQL verb and there is no console verb: a query need is served by the governed reads that already exist. These are the verbs that stand in for one.
search.query- find anything across matters, documents, and parties, scoped to what you may see.audit.query- interrogate the permanent, tamper-evident record of what happened.audit.feed- follow the running audit feed as events land.audit.chain.verify- prove the audit chain has not been tampered with.table.list- list the data tables in a workspace.table.get- read a single table and its shape.row.list- read rows out of a table, fenced to what you may reach.row.get- read a single row by id.
Because each of these passes through the one front door, the answers they give are governed, scoped, and audited in exactly the way a raw SQL result never could be. See Security and permissions for why the verb dispatch is the only trust boundary, and the data model for how the store is shaped behind it.