/ui-control

name: ui-control
description: Open a panel in agentglass's own window, read what is open, or read and change one of its settings. Use when the person asks you to "show me" a Settings page, the machine panel, the bench, a Git modal or a file in agentglass; when you need to know what they are looking at, what is in a chat or on the bench, or what a setting is set to; or when they ask you to change an agentglass setting (theme, accent, diff layout, terminal font, rail order). Not for pages inside the built-in browser (that is browser-use).

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 chat                              # 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                          # what you may read and write
agentglass-ui settings get diff.wrap
agentglass-ui settings set diff.wrap true
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 Lantern schedule dialog, 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, chat, 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). 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.

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, 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). Not notification kinds, channels or voices, the home page, tokens, remote access, the ClickUp token, workspace and write switch, plugin trust or the gate: those are the person's. 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. 3. **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. Five exist, all on a pull request. `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.

The other four are the stage doors: `pr.merge.stage` (repo, number, method, optional subject and body), `pr.comment.stage` (repo, number, body), `pr.review.stage` (repo, number, verdict `approve`/`request_changes`/`comment`, body: required unless approving) and `card.move.stage` (repo, number,