# 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.
Source: https://ivar.run/docs/recipes/read-only-context

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`.

```sh
ivar feature create avatar-url
ivar feature promote avatar-url api
ivar feature promote avatar-url web
ivar session start avatar-url
```

`infra` 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: `ivar` keeps 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](/docs/reference/limitations).
- On Linux, a write to `infra` fails with `EACCES` from the kernel. On macOS, and under `ivar 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: `infra` gets 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](/docs/guide/guards) explains the policy, and [Limitations](/docs/reference/limitations) lists where it stops.