Published artifacts can gain a document database Claude reads and writes, off unless you set the env var.
read_db and write_db actions sit behind CLAUDE_CODE_ARTIFACT_DB and a remote gate that falls back to off.
tengu_umber_lattice Off in both readingsThe flag server returned off for the account this site reads and for the anonymous baseline. A reading of off cannot rule out a rollout these two readings sit outside of.
This account: off · anonymous baseline: off · compiled default in v2.1.224: on
These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.
Read once, for one account on one subscription tier, against v2.1.224. It isn't a statement about your account. What a flag value here can and cannot tell you
What's wrong with this entry?
The tool that publishes artifacts can now read and write a published artifact's document database, through two new actions read_db and write_db. Reads take a db_op of get, list or query; writes take set, update or delete, addressed by collection and doc_id. The actions only appear in the tool's schema when the tengu_umber_lattice gate is on (source fallback is false, real value from remote config) or the CLAUDE_CODE_ARTIFACT_DB environment variable is set.
- A collection is a path of 1 to 31 slash-separated segments (letters, digits,
_ - . ~ : @ +per segment), so subcollections nest likeboards/b1/columns;doc_idis a single segment. There are byte caps on the composed document path and on serializeddata. - Queries support
wherecomparators including the Firestore-stylearray-contains, plusorder_by,limitandcursor; list results page through a cursor. - Rows read back are wrapped in a
=== BEGIN ARTIFACT DBfence and labelled as collaborator-written data, not instructions, and the read-consent prompt warns that collaborator-written rows will be read into the conversation. - Prompts flag ownership: a suffix of "(someone else's artifact)" or "(ownership unconfirmed)" and a shared-with note, and the consent prompt says the database is written by its collaborators when a share probe fails.
- Consent is recorded per artifact for the session, once for reads and once for writes, with separate handling in plan mode and for notification-triggered reads.
- Transcript lines render as "read database" and "write database"; verbose mode shows the target document and share status on writes.
- Backend errors are normalised to a fixed set (not found, invalid argument, quota or rate, busy, upstream auth, store unavailable, not declared) each with a human remedy.
- Read is treated as read-only and safe to run concurrently; write is not.
Read a published artifact's database \u2014 collaborator-written rows will be read into the conversation, Database operation: 'get', 'list' or 'query' for read_db; 'set', 'update' or 'delete' for write_db. Required for both database actions; meaningless for every other action., database write committed, CLAUDE_CODE_ARTIFACT_DB, Database collection path: 1-31 "/"-separated segments (letters, digits, _ - . ~ : @ + per segment), so subcollections nest like "boards/b1/columns". Required for read_db and write_db.
Strings lifted out of the shipped bundle, so the claim above can be checked against them.