Orbit as a Galaxy analysis workbench (standalone + Galaxy Interactive Tool)

[dannon]

What this does

Runs the existing LOOM_MODE=remote Orbit web shell as a per-user agentic analysis workbench, from one image, two ways: standalone (docker run) and as a Galaxy Interactive Tool -- Galaxy launches a per-user container, injects the server URL + a scoped API key, and proxies the user in.

The point is that durable artifacts live in Galaxy: tools/workflows run as Galaxy jobs (outputs are history datasets), and the analysis notebook persists as a per-history Galaxy Page that resumes on relaunch. Meant as a proving ground for ideas that can fold back into Galaxy's own assistant, not a replacement.

What's in here

Notebook -> Galaxy Page persistence (extensions/loom/galaxy-page-sync.ts)

• env-gated (LOOM_GALAXY_PAGE_SYNC=auto), brain-side (pi's rpc dispatch is closed, so the shell just sets the env at spawn and drains the brain on shutdown)
• per-history page identity (orbit-<historyId>), current history via most_recently_used
• debounced push, self-trigger dedupe, fail-open; resume looks the page up by id (a slug 400s on GET /pages/{id})
• wired into session-lifecycle.ts; enabled + SIGTERM-drained in web/server.ts

Galaxy Interactive Tool wrapper (gxit/) -- tool XML (scoped inject="api_key" + $__galaxy_url__, requires_domain entry point) + a deploy guide.

Container fixes (Dockerfile)

• ship web/auth.ts + web/rpc-guard.ts in the runner -- the LOOM_MODE=remote image didn't actually boot without them (ERR_MODULE_NOT_FOUND)
• force TMPDIR=/tmp (Galaxy injects the host's TMPDIR, which tsx can't use)
• bundle uv + pre-warm galaxy-mcp so the Galaxy tool/workflow execution surface loads in-container (node:slim has no Python/uvx)

Remote-mode tool gate (web/extensions/web-mode-gate.ts) -- on a fresh container the galaxy_* MCP tools don't register as direct tools (needs a warm per-server cache, which the per-user key invalidates each launch), so the only path is the mcp proxy. Allow it, scoped to the curated servers (galaxy / brc-analytics); discovery passes, an unscoped call is denied with a message the agent self-corrects on.

Bring-your-own LLM key (web/llm-credentials.ts, web/server.ts, web shim + renderer) -- when the remote shell starts with no provider key in its env, the renderer prompts for a provider + key, the server holds it in memory for the session (never persisted, logged, or echoed -- only a hasApiKey boolean crosses to the renderer) and spawns the brain with it. An admin-injected env key still auto-spawns exactly as before. So the workbench can spread without an admin-baked key. (Standard providers; custom/openai-compatible BYO is a follow-up.)

Testing

New unit tests for the page-sync engine, the gate's proxy scoping, the history helper, and the LLM-credential helpers; full suite green, typechecks clean. Verified live as a real Galaxy Interactive Tool (Galaxy 26.1, interactive tools + gx-it-proxy + Docker): the notebook persisted to a per-history Page, and the agent -- running entirely in the container -- invoked Galaxy MCP through the scoped proxy and ran an upload_file_from_url job that landed a dataset. The BYO-key flow was verified at the WebSocket-protocol level: no env key -> the server reports hasApiKey:false and holds off spawning until the key is provided; an admin env key -> hasApiKey:true + auto-spawn; the key never reaches the logs or config.json.

Notes

• Draft: builds on the shipped LOOM_MODE=remote shell; branch is based on an older main and will want a rebase. Follow-ups: wire BYO for custom/openai-compatible providers (baseUrl + key), and a browser-level eyeball of the BYO overlay.
• Sizable but cohesive. The Dockerfile boot-fix is independently valuable and could be split out as a fast standalone fix if you'd prefer.