Give the agent read-only context repos
Promote only the repos that change, so the agent can read the rest and cannot commit to them.
You need a hall with the repos the change touches and the repos it only needs to read. This example changes api and web and reads infra.
ivar feature create avatar-url
ivar feature promote avatar-url api
ivar feature promote avatar-url web
ivar session start avatar-urlinfra is not promoted, so the agent sees it on its default branch and can read it.
What happens
- Repos you haven't promoted are guarded:
ivarkeeps the agent's writes inside the feature and refuses commits on the default branch. It is a guardrail against agent mistakes, not a security boundary. Kernel-enforced on Linux; see Limitations. - On Linux, a write to
infrafails withEACCESfrom the kernel. On macOS, and underivar session connect, only the worktree root loses its write bit. - Other worktrees of a promoted repo stay writable on Linux. The guard covers repos you did not promote.
- Promoting during a session does not widen the session's write scope. Restart with
ivar session start avatar-url --resume. - Delivery lists only the promoted repos:
infragets no pull request.
If the agent needs to change infra after all, run ivar feature promote avatar-url infra and restart the session. Until then, the preview of your delivery shows which repos will get a pull request, so a repo that should have stayed read-only is easy to spot before anything is pushed.
The agent can still read what it needs. Running ivar session start with no feature opens a discovery session, where every repo is read-only on its default branch, which suits a first pass over an unfamiliar hall. Promote a repo only when its code has to change, and the pull request list follows from that choice. Anything you leave out of the feature cannot end up in a pull request by accident, and the reviewer sees only the repos that changed.
Read the full walkthrough
The guards guide explains the policy, and Limitations lists where it stops.