sirallap/agentglass/ui-control

Driving agentglass's own screen

The window the person works in has panels (Settings, the machine panel, the bench, the Git modals, the file finder) and settings. agentglass-ui is your door to them: the same list of doors a Stream Deck button uses, with a name on every call so the person can see in the action log that it was you.

agentglass-ui list                                   # every door, its level, its arguments
agentglass-ui state                                  # what is open now; which panels `read` describes
agentglass-ui read bench                             # one panel's state, shown nowhere
agentglass-ui open settings.open --arg page=diff --arg row=wrap-long-lines   # quiet: a chip if they are typing
agentglass-ui open --now settings.open --arg page=diff       # they said "show me": at once
agentglass-ui settings list                          # every setting, the window's and the server's, with its class
agentglass-ui settings get diff.wrap
agentglass-ui settings set diff.wrap true
agentglass-ui settings set launch.mode auto           # an escalation: comes back pending, waits for the person
agentglass-ui settings requests                      # what you asked for that still waits
agentglass-ui --as my-agent read view                # put a name on the call

As an MCP server: claude mcp add agentglass-ui -- agentglass-ui-mcp. One tool per door (ui_settings_open, ui_read, ui_settings_set, ...), and the list comes from the running app, so it is always the doors this version has. Set AGENTGLASS_UI_AS to the name your calls carry.

What you can open: every view and Settings page, one plugin's own page (settings.plugin), the machine panel, project picker, window switcher, the bench, a file in the viewer, the Git modals (insights, bisect, the git palette, compare, blame, and the rebase editor, which only draws the plan), one event or session the window holds (event.open, session.open), the running version's release notes (whatsnew.open), the Agents screen's schedule and Change-the-coordinator dialogs, the Terminal's Resume list, and what the pane chords open for the focused terminal pane (pane.open). Opening only shows: starting a rebase, saving a schedule, resuming a session is the person's click. Not doors, on purpose: the people picker, the Rescue modal and the menus inside a panel; agentglass-ui list is the truth.

What you can read: agentglass-ui read <panel> for view, bench, gates and the Settings panes (diff, terminal, browser, notifications, prefs, rail, keys, tasks, appearance, understudy, hooks, lantern, budgets, recipes, review-prompts, saved-replies, tmux, privacy, plugins, log, about) and machine.disk (the disk scan and the cleanup plan: free space per disk, and every line with its id, size and verdict safe, ask, inuse or explain; the ids are under untrusted) and usage.accounts (the accounts a plugin says each provider has: ids and which one is active in state, the labels and plan names under untrusted; never a credential) and usage (how often each view, Settings page and modal was opened on this machine, most opened first: ids and dates, all in state). Panes the server holds ask their own route and can take a moment. Recipe steps, prompt and reply text, plugin settings and credentials are never in an answer; names and titles are under untrusted.

Every answer is one JSON object. ok: true means a window ran the command; ok: false carries one sentence saying why (no window is open, a change is off on this server, the setting is not exposed, an argument is outside its set). Read the sentence and do what it says; do not retry the same call.

Changing any setting: the settings door

settings list names every setting there is, the window's (where: "window": theme, diff, terminal, rail, keys...) and the server's (where: "server": the orchestration policy per project, the worker roles' engine and model, the chair's model, engine and powers, launch permissions, the gate, plugins, budgets, the Lantern, Jira and ClickUp switches). Each row has a class, and the class is what happens when you change it:

• low: applies at once, with a chip that names you (--as) and an Undo.
• escalation: anything that gives agents more power or spends more (a looser

launch mode, a shorter deny list, the gate off, a plugin on, a bigger budget, a dearer model, the policy). Your change becomes a request: the answer says "applied": false, "pending": {...} with the diff, and nothing changes yet. The person sees a card in the corner of their window, with who asked and that diff, written by the server from the value it checked, never by you; they press Approve or Decline. Approve applies exactly that diff, once, and gives you no permission for next time. Unanswered for 30 minutes, it is declined. If the setting moved before they approved, nothing applies: ask again. Do not ask in a loop; settings requests shows what still waits. A change that narrows (stricter mode, longer deny list, gate on, plugin off, smaller budget, longer interval, fewer powers) applies at once, because it makes things safer.

• personOnly: never yours, not even as a request: whether agents are asked at

all ("Let my agents change settings without asking", which only the person turns on, in Settings > Orchestration > Safety and limits) and publishing the machine to the tailnet. You may turn that switch off; you cannot turn it on. secrets.keyring is an escalation to turn on and personOnly to turn off (it writes every token back into plain files). While the person has it on, an escalation applies at once.

• secret: tokens. Never read, never written, by any route.

A setting held per project takes --root (settings set seat.powers speak --root /home/me/code/orbit); a chair speaks only for its own project. A setting whose type is json takes the JSON as text: settings set launch.deny '["Bash(gh pr merge:*)","Bash(curl:*)"]'. The routes the Settings pages use answer the same way (POST /orchestration, /launch-permissions, /seat/settings, /seat/change): 202 with the request instead of a 403. No route, no CLI and no MCP tool answers a request for the person.

The project's agent rules

What an agent may do in a project lives in one list, in agentglass, and every agent obeys it wherever it was started: a run agentglass launched gets it as flags, and a Claude Code or OpenCode session started anywhere else is checked by the hook before each tool call (GET /agent-rules/check). Codex and Gemini have no hook: only the permission mode reaches them.

agentglass-ui rules list # base set, this project's rules, suggestions, history agentglass-ui rules suggest # actions first seen here with no rule yet agentglass-ui rules set 'Bash(git push:)' ask --as <name> agentglass-ui rules set 'Bash(npm publish:)' never --root '*' --as <name>

The MCP twin has ui_rules_list, ui_rules_suggest and ui_rules_set. Each rule is allow, ask or never; when two match, the stricter wins. A rule stricter than what is in force applies at once; a looser one waits for the person on the approval card and changes nothing until they answer.

The person sees and changes the same list on the Agents screen, in the section "What your agents may do": one card per project, a click on Allow, Ask me or Never writes through the routes above, and a suggestion is answered (or dismissed) there by the person alone.

A rule the person tells you in chat goes here, never into your private memory. Memory is read by one agent; this list is obeyed by all of them.

The three levels

1. Look or open. Opens a panel or reads state. Nothing changes.
2. Change a local setting. settings set, and only for the settings

settings list shows (appearance, diff, rail, the terminal, quiet mode and two pull-request notices, the search engine, what Tasks shows, the low-disk warning (prefs.diskWarn: 0 or off, 5, 10, 15, 20), single-key shortcuts, and which ClickUp spaces count for statuses: settings set clickup.statusSpaces.counted 901,902 (settings list says each setting's type; one that stores a string takes digits as text, and display is its value in words), a comma-separated list of space ids, empty for "the spaces my cards live in"; the rest are ignored, not deleted, and the page lists them to count again; a read before the ClickUp page was ever opened may say empty until the first local read lands). What gives agents more power (the gate, plugins, the write switches, the policy) goes through the settings door above and waits for the person; notification kinds, channels or voices, the home page, remote pairing and every token are not yours to reach. The person gets a "<your --as name> changed X" chip with Undo, on screen for a minute (so keep the name: without one it says "An agent"). A refused value says what IS accepted ("accepted: one of split, inline"): correct it from that sentence in one step, do not probe. The palette and the zoom are in this level too, because they persist. The owner can limit the server to level 1: then none of these is offered, and asking anyway is refused with a sentence that says the limit is theirs.

1. An effect outside the app (merge, push, send, anything touching a token,

remote access, plugin trust, the gate or consent). An agent never performs one through this channel: a level 3 door only stages, opening the dialog with its fields filled in, and the person's own click is the effect. There is no grant that makes it automatic. It is offered only when the owner has allowed level 3. If the task needs one and no door stages it, say so and let the person do it. Eight exist: five on a pull request, one in the Finder, one in the machine panel and one in the usage popover. pr.unstick (level 3) opens the Unstick dialog and nothing else; never offer it on a pull request that is merely slow, the dialog refuses one that is not stuck.

finder.op.stage (op trash/move/copy/rename/new-folder/duplicate, path, plus dest for move and copy, name for rename and new-folder) opens the Finder on the path with a confirmation naming you and every path; it never offers Open With or the person's own actions, and delete and empty-trash are refused because they cannot be taken back. Say I prepared the move; it is yours to press, never that you moved anything.

diskclean.stage (ids: line ids from read machine.disk, one per line, at most 40) opens Machine > Resources with those lines of the cleanup plan marked as yours. Only lines the scan calls safe are kept; the panel says which of yours it dropped and why, and the Clean button removes nothing until the person presses it. Running the clean is not a door at all (the route answers 403 to an agent). agentglass-ui stage diskclean.stage --arg ids="$(printf 'docker:cache\ncache:uv')". Say I picked these lines in the cleanup plan; it is yours to look at and press, never that you freed or deleted anything.

usage.account.stage (provider, id: both from read usage.accounts; the account must be in the plugin's list and not the active one, or the server answers 409 with a sentence) puts the usage popover in front of the person with that account marked as your proposal. Switching is the person's own press of the chip: POST /usage/accounts/switch answers 403 to a plugin, a paired device and any agent (the machine token alone included: it takes the desktop window's own desk key), and no door presses it. A provider whose accounts are managed by its plugin (managedBy) cannot be switched from here at all. Say I proposed switching to that account; it is yours to press, never that you switched.