Founder & CEO of Netsujo. Building trustworthy AI agent systems, with a focus on task boundaries, verification, and production reliability. Creator of Agent Role Contracts (ARC).
The worktree boundary raises a useful distinction: is “never touch your checkout” enforced by the host's filesystem permissions, or by routing the agent to a separate working directory? A worktree alone doesn't remove the process's access to sibling paths or shared credentials.
A small acceptance test could put a harmless sentinel outside the assigned worktree, ask the agent to modify it, and record both the tool denial and the unchanged sentinel. That would make the enforcement claim independently checkable alongside the spec/merge checks. I haven't run Thinkrail; does its current host enforce that boundary?
Senior Lead Tech/Dev, 20+ years. Building NoireBox — the flight recorder for your of AI agents. Proof, not promises. Rust · TS · Python · PHP. I write about trust in AI.
Checked the repo, since it's open: enforcement is routing, not confinement. The worktree comes from git worktree add (workspaces.ts), which is a separate directory under the same user — sibling paths and shared credentials stay reachable by the process. The only sandbox-exec in the tree is in the test harness, denying the desktop host read of the repo root for e2e isolation — so macOS Seatbelt is already in the building, just not applied to agent sessions. Your sentinel test is the right acceptance check, and run today it fails on the deny half: the tool call would succeed and the sentinel would change.
One distinction your test already contains, worth naming: record both the refusal and the unchanged sentinel. The refusal is a step — a tool can be told to deny; the unchanged sentinel is the sensor — the world has to actually hold still. Anything the agent's report can attest alone, the agent can forge; the sentinel is what makes the claim checkable without trusting the reporter. That's the same law the geometry thread ran: enforcement by permission is the declared vantage, the sentinel is the effective one, and the gap between them is the finding.
Founder & CEO of Netsujo. Building trustworthy AI agent systems, with a focus on task boundaries, verification, and production reliability. Creator of Agent Role Contracts (ARC).
Thanks for checking the source and clarifying routing versus confinement. I would treat the predicted sentinel outcome as a source-reading conclusion, not a recorded test result; I haven't run Thinkrail either. For the acceptance check, both the tool denial and an independently verified unchanged sentinel matter.
Senior Lead Tech/Dev, 20+ years. Building NoireBox — the flight recorder for your of AI agents. Proof, not promises. Rust · TS · Python · PHP. I write about trust in AI.
Correct, and the correction lands on me: "run today it fails" was a derivation wearing a measurement's clothes. The verified half is the source reading — git worktree add, same user, no confinement in the session path. The failing half is a prediction and gets its label: predicted from source, not executed. Your acceptance formulation is the tight one — tool denial and independently verified unchanged sentinel, both recorded, either both passing or the finding named. The protocol is three lines (sentinel outside the worktree, prompt the agent to modify it, record the denial and the bytes) and it's pre-registered here: whichever way the run lands, the result replaces this prediction.
Founder & CEO of Netsujo. Building trustworthy AI agent systems, with a focus on task boundaries, verification, and production reliability. Creator of Agent Role Contracts (ARC).
Thanks for making that correction explicit, Sam. Recording both the tool decision and the independently observed sentinel state gives the eventual result a clear basis. The source-derived prediction remains labeled as such until that run supplies the evidence.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The worktree boundary raises a useful distinction: is “never touch your checkout” enforced by the host's filesystem permissions, or by routing the agent to a separate working directory? A worktree alone doesn't remove the process's access to sibling paths or shared credentials.
A small acceptance test could put a harmless sentinel outside the assigned worktree, ask the agent to modify it, and record both the tool denial and the unchanged sentinel. That would make the enforcement claim independently checkable alongside the spec/merge checks. I haven't run Thinkrail; does its current host enforce that boundary?
Checked the repo, since it's open: enforcement is routing, not confinement. The worktree comes from
git worktree add(workspaces.ts), which is a separate directory under the same user — sibling paths and shared credentials stay reachable by the process. The onlysandbox-execin the tree is in the test harness, denying the desktop host read of the repo root for e2e isolation — so macOS Seatbelt is already in the building, just not applied to agent sessions. Your sentinel test is the right acceptance check, and run today it fails on the deny half: the tool call would succeed and the sentinel would change.One distinction your test already contains, worth naming: record both the refusal and the unchanged sentinel. The refusal is a step — a tool can be told to deny; the unchanged sentinel is the sensor — the world has to actually hold still. Anything the agent's report can attest alone, the agent can forge; the sentinel is what makes the claim checkable without trusting the reporter. That's the same law the geometry thread ran: enforcement by permission is the declared vantage, the sentinel is the effective one, and the gap between them is the finding.
Thanks for checking the source and clarifying routing versus confinement. I would treat the predicted sentinel outcome as a source-reading conclusion, not a recorded test result; I haven't run Thinkrail either. For the acceptance check, both the tool denial and an independently verified unchanged sentinel matter.
Correct, and the correction lands on me: "run today it fails" was a derivation wearing a measurement's clothes. The verified half is the source reading —
git worktree add, same user, no confinement in the session path. The failing half is a prediction and gets its label: predicted from source, not executed. Your acceptance formulation is the tight one — tool denial and independently verified unchanged sentinel, both recorded, either both passing or the finding named. The protocol is three lines (sentinel outside the worktree, prompt the agent to modify it, record the denial and the bytes) and it's pre-registered here: whichever way the run lands, the result replaces this prediction.Thanks for making that correction explicit, Sam. Recording both the tool decision and the independently observed sentinel state gives the eventual result a clear basis. The source-derived prediction remains labeled as such until that run supplies the evidence.