CLI: omnigraph studio launcher and graph owner discovery #980

Disposition — 2026-10-20

Closed as not planned: the proposed second serving model is discontinued.
This includes in-process standalone graph hosting, generated local credentials,
graph-owner discovery, attach/reuse, and the later proposal for Studio to start
and own a serve --reuse process. This disposition supersedes those proposals
in the issue body and discussion.

OmniGraph retains the ordinary cluster-backed server on localhost and remote
hosts. Studio may connect to that existing HTTP server. Independent client
integration remains in draft #1017; it does not revive local hosting or an owner
registry. Implementation PRs #1075, #1077 and #1083 are closed without merging.

Historical proposal

Problem

There is no way to open a graph in Studio, OmniGraph's desktop client, from the CLI. A local graph also has no owning process for later CLI commands to attach to.

Proposal

omnigraph studio

• Resolve the target the way other commands do (--store, --cluster --graph, --server --graph, profile).
• For a local target, serve it in process on loopback. Bind 127.0.0.1:0; refuse any other Host, refuse a mismatched Origin, send no CORS headers.
• For a server target, pass the server through.
• Mint a per-launch token for operator.actor, and open Studio with a single-use code: omnigraph-studio://connect?code=…. Studio already registers the omnigraph-studio scheme and handles graph, node and query links; connect is the missing route. Studio redeems the code once at the loopback server for its token.
• Never put a token in argv. Print the URL; --no-open --json for SSH and agents.
• Include the launching binary's path and HTTP contract in the handoff, so Studio can give agent sessions on that graph the same CLI.

Owner discovery

• A file under $OMNIGRAPH_HOME names the process, port and session that own a graph root.
• A second omnigraph studio attaches instead of opening a second writer, and CLI commands against that root can route through it.
• Discovery only: publication safety stays with the manifest version CAS. A process-local lock is not distributed fencing.

Writer-safety rules for local sessions:

• default to read-only;
• never take cluster admission from Studio;
• refuse writes without an actor;
• never replay a write whose outcome is unknown.

Depends on a supported local-embedding constructor in omnigraph-server instead of the test-shaped helpers. Read-only mode must refuse mutating routes at the router.