GSO-1
Ops Room

An agent with the run of your machine, on a short leash.

The Ops Room is where you ask GSO-1 questions about your own machine and let it act on the answers. It runs on a model you host, inside a directory it cannot write outside of, and it asks before it changes anything.

01 / What it isA staff officer you can talk to

The rest of GSO-1 is a dashboard: it shows you the situation and gives you buttons. The Ops Room is the part you can ask. "Which repos have uncommitted changes?" is a question the dashboard answers by making you look. The Ops Room answers it by looking for you, across every project root, and telling you which ones and how many files.

It is not a general-purpose chatbot bolted onto a dashboard. It has a specific, small set of tools, all of them about the machine it runs on, and no ability to do anything outside them. That narrowness is the point: an agent that can only do ten things can be trusted with those ten things.

The tools it actually has

list_apps

Every project across your roots, with its detected kind and whether it is running.

git_status

Branch, dirty file count, ahead/behind and last commit for one repository.

git_dirty_sweep

The same across every repo at once. This is the one that answers "what have I left unfinished".

uptime_info

What is running, on which ports, and for how long.

build_release

Snapshot the current working tree into a versioned release.

verify_release

Health-check a release before anything depends on it.

promote_release

Point var/current at a verified release.

rollback_release

Go back to the previous one when a promotion turns out badly.

release_status

Which release is live, which are on disk, what changed.

web_search

Look something up. Disabled entirely unless TAVILY_API_KEY is set.

Plus reading and writing files, which is where the sandbox below matters.

02 / The leashThree rings, and a human at the gate

An agent that can start processes and edit files on your machine is a real capability, so the limits are structural rather than a promise in a prompt.

Sandbox root
The only directory the agent may write to. It resolves from the install location, so it is wherever GSO-1 actually lives. Override with OPSROOM_SANDBOX_ROOT.
Read roots
What it may read, search and list: the sandbox plus your configured project folders. Override with OPSROOM_READ_ROOTS.
Immutable
Never writable, even inside the sandbox: the supervisor, var/, and the launcher. The supervisor is what rolls back a bad self-edit, so the agent must never be able to touch it.

Every check resolves symlinks and .. before deciding, so sandbox/../../etc/passwd and a symlink pointing outside both fail closed rather than open.

Approval

Anything that writes a file or runs a command stops and asks. The request goes to the same Allow / Deny gate GSO-1 already uses for Claude Code sessions, so there is one approval mechanism on the machine rather than two, and it can reach you on Telegram when you are not at the desk. Read-only tools run without asking, because stopping you to approve a git status would train you to approve everything.

The honest version

GSO-1 starts processes and runs commands as you, and the Ops Room is that capability with a language model driving. The defaults are conservative and the sandbox is enforced in code, but this is a tool that does things to your machine. Read the security policy before you open it up to anything beyond loopback.

03 / The modelConnect your local LLM

The Ops Room talks to an OpenAI-compatible endpoint. In practice that means llama.cpp's llama-server running on your own hardware, so no part of a session leaves the machine and there is no per-token cost to think about.

1. Start a model

Any tool-capable GGUF will do. Tool use is the requirement that actually matters: a model that cannot call tools reliably will hold a nice conversation and do nothing.

# --jinja is not optional: it is what makes tool calling work
llama-server \
  --model ~/models/your-model.gguf \
  --host 127.0.0.1 --port 8080 \
  --ctx-size 65536 \
  --jinja

Or start it from the dashboard: the Local LLM tab lists the models on disk, loads one, and shows tokens per second, context use and memory while it runs.

2. Point the Ops Room at it

# defaults, override in .env if yours differ
OPSROOM_LLAMA_URL=http://127.0.0.1:8080/v1
OPSROOM_MODEL=glm-4.7-flash
OPSROOM_CTX=65536
OPSROOM_MAX_TOKENS=4096
VariableDefaultWhat it controls
OPSROOM_LLAMA_URLhttp://127.0.0.1:8080/v1The OpenAI-compatible endpoint to talk to.
OPSROOM_MODELglm-4.7-flashModel id, as the server reports it.
OPSROOM_CTX65536Context window. The tool schemas alone cost roughly 1,300 tokens, and a full dirty-repo sweep can return several thousand, so a small window runs out fast.
OPSROOM_MAX_TOKENS4096Cap on a single reply.
OPSROOM_SANDBOX_ROOTthe install directoryThe one writable root.
OPSROOM_READ_ROOTSsandbox + your project foldersComma-separated readable roots.
TAVILY_API_KEYunsetEnables web_search. Without it the tool disappears rather than failing.

3. Ask it something

# from the dashboard: the Ops Room panel, or Cmd+J
# from a terminal:
./ops "which repos have uncommitted changes?"
./ops "is anything holding port 3000?"
./ops "build a release and verify it, but do not promote"

A note on model size

Local tool-use reliability varies enormously between models, far more than chat quality does. A model that writes beautifully may still call a tool with the wrong argument shape and then confidently summarise a result it never received. If the Ops Room is behaving oddly, the model is the first thing to change, not the prompt.

04 / Self-updatingWhy it edits code it is not running

The Ops Room can change GSO-1 itself, which is a genuinely dangerous thing to let an agent do, because a bad edit can kill the process making it before anything notices.

So the running agent executes from the promoted release while it edits the working tree. Those are different directories on purpose. An in-progress edit cannot touch the code currently executing; new code only takes effect once a release is built, verified and promoted, and a promotion that fails its health check rolls back.

This is not hypothetical caution. A broken self-edit killed the agent mid-task during development, before verification could refuse it. The separation is what came out of that.