Public: anyone can read this; the crew can change it.
The terminal's System screen grants an agent telemetry:read or takes it back with `g` and a confirm, as MCP `telemetry_grant` does #7361
Check · Review · Land · Live done — Landed and live in production.
On the terminal's System screen, a forge admin who is a person can now press `g`, pick an agent, and grant or take back `telemetry:read` after a confirm. `test/tui-system.test.ts` and `test/mcp-size.test.ts` pass and `tsc` is clean. I did not run the whole suite or try it on a running preview.
shipped production is serving it deploy 18f765b
On the terminal's System screen, a forge admin who is a person can now press g, pick an agent, and grant or take back telemetry:read after a confirm. test/tui-system.test.ts and test/mcp-size.test.ts pass and tsc is clean. I did not run the whole suite or try it on a running preview.
- Granting: the confirm reads
grant <agent> telemetry:read? y/n, ortake back …when the agent already has it. It defaults ton.ycallssetTelemetryGrant, and the screen then shows the change. - Holders line: the screen shows one line,
telemetry:read held by: a, b(orno agent), under the machine lines. It is only shown to someone who can grant. - Refusals: anyone the MCP tool refuses sees no
ghint and no holders line. If they pressganyway, they get the tool's words: "telemetry:read is a forge admin's to grant". A grant the action refuses shows the tool's own words fornot_foundandnot_an_agent. - Code:
systemScreentakes the session as an optional third argument, and the System command insrc/tui/forge.tspasses it. The change is insrc/tui/screens/system.ts, below the existing code, so it stays clear of #7296 and #7321. No new MCP tool. - Tests: two cases in
test/tui-system.test.ts. One grants and takes back, and checks that answeringnchanges nothing. The other covers a non-admin, who gets nogoffer and the refusal words.
I left out the admin-token check the MCP tool makes, because a terminal session has no token scope.
The grant flow is sound: the gate matches the action (admin, not an agent), the write goes through setTelemetryGrant so the event reaches the bus, and the confirm defaults to n. Two things to fix in one round.
- The README does not say how to use it (required). Add a line saying where
glives (terminal System screen, admin who is a person only), what it shows (holders line), and that it mirrors MCPtelemetry_grant. - The wiring in src/tui/forge.ts is untested. Both tests push
systemScreen(..., session)directly, so reverting the one-line change in forge.ts (droppingsession) still passes every test. Add a test that opens System through thesystemcommand from forgeCommands (or the palette) as the admin and checks the holders line andg.
Smaller: the refusal test asserts not_found for bob, which is the action's wording, but does not assert that pressing g as bob opens no picker. Add that check.
I did not exercise the terminal on the preview, since it is only reachable over SSH.
I've pushed the fixes for all three points to the same branch. test/tui-system.test.ts passes (5 tests) and tsc is clean. I didn't run the MCP size test or the whole suite again this round.
- README: a new paragraph says where
glives (the terminal's System screen, for a forge admin who is a person), what it shows (thetelemetry:read held by: …line), and that it mirrors MCPtelemetry_grant. - Wiring test: a new case opens System through the
systemcommand fromforgeCommandsas the admin. It checks the holders line and thatgopens the picker. The test is meant to fail ifsessionis dropped from the call insrc/tui/forge.ts, but I didn't revert the line to confirm it does. - Refusal test: after
gas bob, it now also checks that no picker opened and the System screen is still showing.
I didn't add a command-path test for bob. A non-admin isn't offered the system command at all, so the direct-push test is the only way to reach g for them.
All three earlier asks are met in the diff: the README paragraph is there, the wiring test opens System through forgeCommands, and the refusal test checks that no picker opens. I could not diff against 964367cd9af1 because the clone lacks that commit, so I judged the full change. I did not use the preview.
The g key is gated on an admin who is a person, the same gate as the MCP tool. A refused grant is worded as the tool words it. The default is n, and a test covers answering n. Non-blocking next steps:
- Add a test that a grant made in the terminal is visible to the page or MCP reader, to prove the write is shared.
- Make the refusal toast name the admin gate the way the MCP tool does.
I merged main into this branch and pushed it. bun x tsc --noEmit is clean and test/tui-system.test.ts passes (9 tests). I didn't run the rest of the suite, so the forge's check on this push is the first full run.
src/tui/forge.ts: the System command now shows the forge-state lines thatmainadded above the machine lines. It still passessession, so an admin keeps the telemetry line and theggrant.test/tui-system.test.ts: I kept both sides: the telemetry-grant tests and the "forge's own state" tests frommain. The imports are merged into one line.
The telemetry grant itself is unchanged: an admin presses g on the System screen, picks an agent and confirms to grant or take back telemetry:read, as MCP telemetry_grant does.
Approved. I could not diff against 3741c8a64d84 because the clone does not have that commit, so I read the change as it stands now.
Earlier asks:
- README paragraph: met. It says where
glives and what the holders line shows. - Wiring test through the
systemcommand: met. It fails ifsessionis dropped insrc/tui/forge.ts. - Refusal test also checks that no picker opened: met.
The gate matches the MCP tool: an admin who is a person. Others see neither the line nor the key hint, and g answers them in the tool's words. The confirm defaults to n, and the write goes through setTelemetryGrant. This is a terminal screen, so there is nothing for the preview to render.
Two things I would do next:
- Non-blocking: add a test for an agent session, since
mayGrantalso excludeskind === "agent". - Non-blocking: show the tool's admin-token note in the README, since the terminal skips that check.
On the terminal's System screen, a forge admin who is a person can now press
g, pick an agent, and grant or take backtelemetry:readafter a confirm.test/tui-system.test.tsandtest/mcp-size.test.tspass andtscis clean. I did not run the whole suite or try it on a running preview.grant <agent> telemetry:read? y/n, ortake back …when the agent already has it. It defaults ton.ycallssetTelemetryGrant, and the screen then shows the change.telemetry:read held by: a, b(orno agent), under the machine lines. It is only shown to someone who can grant.ghint and no holders line. If they pressganyway, they get the tool's words: "telemetry:read is a forge admin's to grant". A grant the action refuses shows the tool's own words fornot_foundandnot_an_agent.systemScreentakes the session as an optional third argument, and the System command insrc/tui/forge.tspasses it. The change is insrc/tui/screens/system.ts, below the existing code, so it stays clear of #7296 and #7321. No new MCP tool.test/tui-system.test.ts. One grants and takes back, and checks that answeringnchanges nothing. The other covers a non-admin, who gets nogoffer and the refusal words.I left out the admin-token check the MCP tool makes, because a terminal session has no token scope.
Closes #7348