[ymote]

ADR 0004 plan step 4: the system agent's tool set (§12, as accepted).

What changes

Before this PR, the system agent's turns got octos's full default tool set, octos's shell included. Now:

• One definition in crates/kernel/src/system_tools.rs:
  • SYSTEM_AGENT_TOOLS: the system agent's default octos tools. These are supervision (peer_send_input, peer_gather, peer_list, peer_respond, peer_close), workspace-fenced file tools, memory, ask_user_question, media viewing, web_search/web_fetch (until toolbox-peers: offer the system toolbox to app agents (ADR 0002 §6, behind a feature) #108's toolbox grants replace them) and tool_search.
  • SystemAgentTools: its grants. These are toolbox tools, cross-app tools and grant_command_execution (the Settings switch, off by default). When the switch is on, the host tool terminal.run is added, and each command needs a live approval. Persisting the switch is a TODO (no Settings plumbing exists yet), and so is registering the tool on the system session (needs octos#2567 item 6).
• The profile policy. Every kernel start writes the _main profile's tool_policy: everything a grant can give, minus octos's own shell (group:runtime: shell, bash, exec_command, write_stdin). octos applies it to every turn of the profile, including kernel wake continuations.
• The only exclusion: octos's own shell. §12 says OctoSense hard-codes no exclusions, and delivers command execution only as a host tool with a live approval (terminal.run), run by the shell where it can be approved, audited and shown. octos's shell runs commands inside the kernel with none of that, so no grant gives it. This is the only exclusion. Schedules, sub-agents, check, git, goals, admin, plugin and MCP tools all stay grantable. If a later reading of §12 makes octos's shell grantable too, it is one line (OCTOS_SHELL, marked with a TODO).

What is enforced, and what is not

• §12's "exactly its grants" is NOT yet enforced for the system agent. It never gets octos's shell, but otherwise it is bounded by the grantable ceiling, not its list. Its exact list needs session-targeted registration and tool lists in octos: octos#2567, reviewer item M1 (our item 5).
  • The exact-list real-kernel test is kept and #[ignore]d with that reason. Run with --ignored today, it fails, and the failure shows the gap.
• App peers are not capped below what they can be granted. Each peer is narrowed to its grants by its turns' generic_tools (plan step 6). Host-routed tools are registered after the policy, so the policy never strips them.
• Talk to Octos external clients are unaffected. octos confines their turns to its allowlist, which contains no shell. A real-kernel test checks this.

Whose octos home (review HIGH 1)

The desktop kernel used ~/octos-home/.octos, the person's own octos home, shared with their standalone octos. Writing a tool policy there would have changed their standalone octos.

• OctoSense's own core dir. On every platform the core dir is now <app data dir>/octos-home/.octos. On a desktop the shell passes OctoSense's state dir, so the core dir is ~/.octosense/octos-home/.octos. $OCTOS_APP_CORE_DIR and an explicit core dir still win.
• One-time, copy-only migration. When OctoSense's own profile does not exist yet, the kernel copies only the provider and model settings (config.llm, config.env_vars, i.e. keychain markers or saved keys) from ~/octos-home/.octos/profiles/_main.json. Nothing under ~/octos-home is ever written, moved or deleted, and no tool policy or other setting is carried over. This happens only on a desktop whose core dir comes from its data dir.
• Defence in depth. enforce replaces only a policy OctoSense wrote ("owner": "octosense", a field octos ignores), or writes one where there is none. A foreign policy is refused with a warning, and so is the person's own ~/octos-home/.octos, policy or not.

octos changes needed

1. Session-targeted tool lists (octos#2567 M1, our item 5), so the system agent gets exactly its grants. It would sit next to the profile policy re-apply at crates/octos-cli/src/api/ui_protocol_transport.rs:37495 and the external restriction at :37513 (and session_actor.rs:3847), set through SessionOpenParams (octos-core/src/ui_protocol.rs:2033) or a new host-only method.
2. Host tools on the system session (our item 6). #2567 registers them per app peer only. The system session needs the same for granted toolbox and cross-app tools and terminal.run.

Tests (real kernel = octos 5e7577f built locally)

• Kernel unit tests:
  • the policy excludes octos's shell and nothing else;
  • grants join as host tools, never as shell;
  • enforce writes ours, keeps the other keys and replaces only our own policy;
  • it refuses a foreign policy and the person's own octos home, leaving both untouched;
  • core-dir resolution and the migration: copy once, only provider settings, source tree byte-for-byte unchanged, never over an existing profile. All in temp dirs; the real ~/octos-home is never touched.
• Kernel real kernel:
  • a system-agent turn over stdio and over Talk to Octos is offered no octos shell and all of its own tools;
  • an older OctoSense policy that allowed shell is replaced;
  • an external turn keeps its allowlist;
  • the exact-list test is ignored.
• App-peers real kernel: no request in the question/answer exchange (host turn, wake continuation, peer turns) offers octos's shell, and the system agent cannot get a command run through an app peer.
• Other checks: cargo build --locked -p octosense, tools/check-shell-graph.sh -p octosense, the octosense-shell and octosense-ai-host tests, and clippy on the touched crates.

🤖 Generated with Claude Code