Managed data access
This guide covers data credentials for an existing managed cluster. Complete
This guide covers data credentials for an existing managed cluster. Complete managed login and cluster selection first; data authority is separate from that control-plane session.
After configuring a complete managed target and supplying its selected profile's
credential (login for an omnigraph profile), run:
omnigraph graphs list --target production --discovery
omnigraph query find_person --target production --graph knowledge --params '{"name":"Alice"}' --json
omnigraph mutate add_person --target production --graph knowledge --params '{"name":"Alice"}' --jsonThe target references a profile for API, organization and one auth provider, and
pins cluster ID, incarnation and data endpoint. See operator configuration. A graph operation requires --graph or that target's
default_graph. Discovery lists graph IDs; it never selects one.
The CLI acquires a missing or expired data credential before submitting the
operation. Human profiles and stored-token profiles use the OS secure store.
Explicit env/file/exec profiles instead keep exchanged credentials only in the
current invocation's memory; they do not probe the OS store or select this path
after a store failure. Managed-target credential export follows the same rule.
External sources still require control-plane identity verification and exchange.
Authentication refresh never replays a submitted mutation.
cluster token --target production --ttl 1h is explicit persistent credential
administration and requires the OS secure store, even with an external source.
The issuer must support identity credentials and admit your principal to the
selected cluster. The credential proves who you are and which cluster you
can connect to; it contains no graph or action permissions. The cluster's
applied Cedar policy supplies those permissions.
For the example's stored queries, it must permit invoke_query plus read
or change. Ad-hoc query and mutation source uses read or change
respectively. Control-plane admin or apply permission does not confer graph
permission.
Apply graph policy grants, revocations and binding changes through the cluster configuration workflow; editing a source file alone has no effect. Changes use the cluster configuration workflow; identity credentials do not bypass its ownership or permission checks.
Issuance takes no --graph; choose a graph on the
operation that needs it. --ttl accepts seconds or an s, m, h, or d
suffix, defaults to one hour, and must be between 60 seconds and 24 hours.
The service can shorten the requested lifetime. Issuer clock tolerance is
30 seconds; a credential is never accepted after its stated expiry.
--json and human output contain metadata only, never the signed credential.
Discover graphs
With a cached identity credential, graphs list --target production
shows every graph ID and display name in the server's applied inventory,
including graphs that failed to open. It does not reveal availability,
storage locations, schema, stored queries, or graph contents. A display name
currently equals its graph ID. Listing a graph does not grant access to it;
an absent policy or unknown policy actor still denies protected operations.
Use --discovery for this minimal inventory on either managed or standalone
server targets. Without it, graphs list requests graph metadata and requires
graph_list policy permission. The CLI does not guess the credential type from
its appearance. A server without discovery support, or an incompatible static
credential, refuses without falling back to another inventory.
Cached access and routing
Data credentials belong to the selected profile and resource binding, including endpoint and incarnation. They remain separate from control sessions; there is no plaintext cache or control-token fallback at the graph endpoint. Use credential export to explicitly release a cluster-bound data token to another process through a pipe.
Managed and standalone access use the shared served graph client: query/mutation,
load, schema reads, branches, snapshots, history, export, Blob operations and
change feeds remain subject to server capabilities and policy. Direct-only
maintenance, schema changes and root administration do not acquire storage
access. --as remains refused on managed targets.
A valid data cache must match the captured endpoint, incarnation and identity. A cached human sign-in or unchanged stored-token profile can support data access during a control outage until expiry or signing-trust retirement. Replacing or removing a stored token invalidates its cache generation. External env/file/exec profiles require control verification and invocation-only exchange; do not assume universal control-plane independence. Missing or expired access uses only the selected provider; auth never falls back or replays an uncertain write.
Managed JSON requests refuse redirects and accept at most 8 MiB of response data, with a 30-second deadline and at most 10 seconds to connect. A lost write response never triggers an automatic retry. Managed loads have the bounds below; Blob and streaming operations keep their own bounds.
Use commit list --target production --branch main --graph knowledge --json
and commit show COMMIT_ID --target production --graph knowledge --json to
inspect native lineage after an uncertain write. Commit identity, parents and
actor attribution are evidence; a timeout alone never proves that a mutation
failed to commit.
An explicit --target staging selects staging independently of source directories.
Configuration and cached credentials cannot silently reroute an invocation.
Preserve original recovery evidence when changing targets or credentials.
macOS Keychain access failures
An upgrade can change the executable identity trusted by a Keychain item. Ad-hoc signing does not provide a stable identity across builds. Stable release trust requires consistent Developer ID signing and a fixed signing identifier; an existing item approved for an ad-hoc build can still require authorization when moving to a signed release. Several items can share the same service label, so approving one item does not approve every session and data-cache entry.
Inspect the installed executable without reading credentials:
codesign -dv --verbose=4 "$(command -v omnigraph)"
codesign -d -r- "$(command -v omnigraph)"On a secure-store failure, retain the operation, classified reason and numeric
OSStatus when present, together with omnigraph version. Do not export secrets
to diagnose it. An authorization failure alone does not prove that a password
is wrong, a keychain is locked, or a credential is missing. Do not repeatedly
approve prompts, delete or reset the keychain, allow all applications, or disable
signature checks as a workaround. Report repeated prompts to the maintainer.
See Apple's code identity requirements.
Clear a credential
cluster token --target production --clear forgets that cluster's persistent local data
entry independently of its control session. Do not combine --clear with
--graph or --ttl. Clearing is not server revocation: copies remain usable
until expiry or signing-key retirement. logout --profile work clears the
selected local session and its derived data cache, then requests provider-session revocation;
provider_revocation_confirmed reports its outcome. Copies of issued data
credentials can remain valid remotely until expiry or signing-key retirement.
Local clearing does not require network transport. Logout also removes local custody when the configured CA is unavailable or proxy selection fails, reporting remote revocation as unconfirmed rather than retaining the session.
Bulk loading
Use the ordinary load syntax with the selected target, an explicit
graph and mode. The native CLI sends the exact UTF-8 NDJSON body to the
authenticated data endpoint; it does not write storage directly.
omnigraph load --target production --graph knowledge --data batch-01.jsonl --mode append --branch review --from main --json
omnigraph load --target production --graph knowledge --data batch-02.jsonl --mode append --branch review --jsonEvery load requires change for that graph. --from additionally requires
branch_create when creating the target branch. Applied Cedar policy owns
target change permission and the base-to-target creation permission.
Identity credentials add no action ceiling. invoke_query is not required for loading.
Review and merge use the existing branch operations and their separate
permissions; a load does not merge its target branch.
One managed load accepts at most 32 MiB (33,554,432 bytes) of input. The
CLI checks this before sending the request. Incremental append and merge
also retain the engine's 8,192 rows and 32 MiB per keyed table bounds, plus
32 MiB across retained keyed batches and a separate parsed-payload estimate
across types. Strict loads check projected in-memory size too. The NDJSON byte
bound does not prove that a batch fits those
engine limits.
Split prepared append and merge inputs into suitable batches, preserving
endpoint dependencies and recording each batch's returned commit. Blob values carry
their own limits.
overwrite also refuses when the IDs it removes exceed 32 MiB per
operation, summed over all touched types. Each removed ID is charged its UTF-8
length plus 24 bytes, so the allowance holds 671,088 IDs of 26 bytes, the
length of a generated ID. Entities loaded without a @key and without an
explicit id get a new generated ID on every load, so overwriting them removes
every committed ID of that type. A delete and the edges it cascades to draw on
the same allowance. No setting changes it. An overwrite cannot be split; a
delete can be split into several commits.
The request has a 300-second deadline, including receipt download, with
at most 10 seconds to connect and 8 MiB of response data. The CLI
never follows redirects or automatically retries the load. A timeout,
interrupted connection, response-limit failure, or invalid receipt can occur
after the server created a branch or committed data. Preserve the batch,
target and any response, then inspect that branch before deciding whether to
retry. --from is not an idempotency key. A success receipt's
commit.actor_id records the authenticated actor.
These managed bounds apply only to managed targets. Direct and server targets use their own credential and transport contracts.