# The Log Sent Us to the Wrong File

An operator deployed an agent with `co deploy --to`, opened its journal, and
saw a reassuring line: the invite was set in `.env`. They went to
`/srv/<agent>`, looked for that file, and found nothing useful. The agent was
running and invitations worked, yet the one diagnostic meant to explain the
door had sent them to a file the service did not read.

The first instinct was to make the deployment copy its secrets into the
project directory. That would have made the log literally true, but it would
also have undone an important boundary. The project tree belongs to rsync and
`--delete`; the real deployment secrets live in a root-owned file at
`/etc/connectonion/<agent>.env`, outside that tree, with mode `0600`.

The complication was that Host is also used locally. It can describe an
environment variable, but normally it cannot know which file populated the
process environment. Hard-coding the server path in Host would make local
diagnostics wrong in the opposite direction.

The turn was to let the systemd unit state the fact it already knows. Alongside
its `EnvironmentFile`, the unit now supplies a non-secret marker naming that
file. Host uses the marker only in its diagnostic. A deployed agent says
`CO_INVITE_CODE` is in `/etc/connectonion/<agent>.env`; a local agent continues
to name its local `.env`. Missing-code guidance follows the same source.

The secret did not need to move. The diagnostic did. The reusable lesson is
that when one layer loads configuration for another, it should pass provenance
along with values—otherwise a perfectly secure storage design can still become
an operational trap.