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

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

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

opened this

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, or take back … when the agent already has it. It defaults to n. y calls setTelemetryGrant, and the screen then shows the change.
  • Holders line: the screen shows one line, telemetry:read held by: a, b (or no agent), under the machine lines. It is only shown to someone who can grant.
  • Refusals: anyone the MCP tool refuses sees no g hint and no holders line. If they press g anyway, 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 for not_found and not_an_agent.
  • Code: systemScreen takes the session as an optional third argument, and the System command in src/tui/forge.ts passes it. The change is in src/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 answering n changes nothing. The other covers a non-admin, who gets no g offer 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

commented

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, or take back … when the agent already has it. It defaults to n. y calls setTelemetryGrant, and the screen then shows the change.
  • Holders line: the screen shows one line, telemetry:read held by: a, b (or no agent), under the machine lines. It is only shown to someone who can grant.
  • Refusals: anyone the MCP tool refuses sees no g hint and no holders line. If they press g anyway, 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 for not_found and not_an_agent.
  • Code: systemScreen takes the session as an optional third argument, and the System command in src/tui/forge.ts passes it. The change is in src/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 answering n changes nothing. The other covers a non-admin, who gets no g offer and the refusal words.

I left out the admin-token check the MCP tool makes, because a terminal session has no token scope.

Changes requested — before the latest push

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.

  1. The README does not say how to use it (required). Add a line saying where g lives (terminal System screen, admin who is a person only), what it shows (holders line), and that it mirrors MCP telemetry_grant.
  2. The wiring in src/tui/forge.ts is untested. Both tests push systemScreen(..., session) directly, so reverting the one-line change in forge.ts (dropping session) still passes every test. Add a test that opens System through the system command from forgeCommands (or the palette) as the admin and checks the holders line and g.

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.

commented

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 g lives (the terminal's System screen, for a forge admin who is a person), what it shows (the telemetry:read held by: … line), and that it mirrors MCP telemetry_grant.
  • Wiring test: a new case opens System through the system command from forgeCommands as the admin. It checks the holders line and that g opens the picker. The test is meant to fail if session is dropped from the call in src/tui/forge.ts, but I didn't revert the line to confirm it does.
  • Refusal test: after g as 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.

Approved — before the latest push

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:

  1. Add a test that a grant made in the terminal is visible to the page or MCP reader, to prove the write is shared.
  2. Make the refusal toast name the admin gate the way the MCP tool does.
commented

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 that main added above the machine lines. It still passes session, so an admin keeps the telemetry line and the g grant.
  • test/tui-system.test.ts: I kept both sides: the telemetry-grant tests and the "forge's own state" tests from main. 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

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 g lives and what the holders line shows.
  • Wiring test through the system command: met. It fails if session is dropped in src/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:

  1. Non-blocking: add a test for an agent session, since mayGrant also excludes kind === "agent".
  2. Non-blocking: show the tool's admin-token note in the README, since the terminal skips that check.
Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs