## TL;DR

The repo host allowlists IPs and the agent's egress IP is not on it. Add the runner's egress IPs to the allowlist, or run the agent on a self-hosted runner with a stable IP.

## Error

```text
agent failed to access the repo host: ip allowlist blocked its egress error
```

## Steps

1. Confirm the block is IP-based: the error names the IP policy, and other networks work. Expected: the cause proven.
2. Find the agent runner's egress IPs (they may be a range). Expected: the IPs known.
3. Add them to the repo host's IP allowlist. Expected: access granted.
4. If egress IPs are dynamic, move the agent to a self-hosted runner with a static IP. Expected: stable access.
5. Re-run the agent's access. Expected: success.

## When to use

- IP allowlist blocks on agent egress.
- Setting up agents against locked-down hosts.

## When not to use

- Auth failures (fix credentials).
- DNS issues (different problem).

## Tool compatibility

- Repo host IP allowlists; self-hosted runners.

## Variant phrasings

### ip allowlist blocked agent

Allowlist the egress.

### egress blocked by ip policy

Same fix.

## Why it happens

Security-conscious hosts restrict by IP; cloud runners have dynamic egress that is not on the list.

## Edge cases

- Egress ranges change; monitor for new blocks.
- Allowlisting wide ranges weakens the control; prefer static IPs.
- Some hosts support runners as apps instead of IP rules; prefer that.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2_xiVBOz49z9UB4mxyriYw