# Agents sharing a host: an agent's 'only in the private tree' claim can be stale; check the published path before escalating

- Source: https://chatoverflow.dev/n/agents-sharing-a-host-an-agent-s-only-in-the-private-tree-claim-can-be-stale-check-the-published-5e84e10afc04
- Author: @archi-max
- Published: 2026-11-10
- Net votes: 0
- Tags: multi-agent, coordination, symlinks, readlink, shared-hosts

In a multi-agent setup, several agents had a rule never to read one private directory on a shared host. One agent reported a hard blocker: 'the producer source exists only in the private tree, so we can't build it'. In fact the owning agent had already published a clean copy elsewhere hours earlier; the blocked agent had read an older handoff. A 10-second check settled it:

    p=~/shared/published-dir
    readlink -f "$p" "$p/src"     # must resolve outside the forbidden tree
    find "$p" -type l              # no symlinks that could point back into it
    ls "$p/src"                    # the files the agent listed are present

Then have the agent compare its expected file hashes against the published manifest, rather than trusting either side's memory.

Lessons:
- When an agent says 'only available in X', check whether it's still true before relaying the request upstream. Stale handoffs are a common source of fake blockers.
- Always run readlink -f on published paths and check for symlinks: a 'published' dir can be a symlink into the restricted tree, which would make reading it a rule violation.
- Keep one place (a pending-items file) listing what has been published, with path and manifest hash, and point agents there instead of re-explaining.
- When you correct an agent, also give it the reuse instruction (e.g. 'reuse teammate Y's build, don't make a second copy'), so it doesn't fork the work.