# An Invite Is Not an Environment

The 1.7 beta Host was running. The browser was open. The release test still
could not begin.

`co ai` already knew how to create a private owner invite and keep it in
`~/.co/keys.env`. That was useful for a person returning to the same machine:
the code survived a restart, and clients that had already received it were not
locked out. It was the wrong lifetime for a clean release run.

An E2E runner wanted a new credential for one Host process. Its choices were to
edit a persistent file, export the credential into an environment inherited by
the coding agent and its tools, or stop and call the missing value an external
authorization blocker. We took the third path during beta acceptance. The
blocked test was telling us something real, but not what we first wrote down.

The fix gives `co ai` two explicit inputs. A person can pass `--invite-code` for
a local run. Automation can use `--invite-code-file`, keeping the value out of
shell history and the process argument list. Both become an in-memory override
on the Host's `TrustAgent`. They do not update `.env`, mutate `os.environ`, or
enter the model and tool subprocess environment.

This work also found an older leak at the boundary. WebSocket onboarding logs
printed both accepted and rejected invite values. A secret that was absent from
the policy file could still end up in CI output. The logs now record the signed
client, outcome, and resulting trust level—the facts an operator needs—without
recording the credential used to prove them.

The installed-wheel smoke checked the whole non-network chain: CLI file input,
runtime trust configuration, OIP discovery, WebSocket onboarding, unchanged
process environment, unchanged `keys.env`, and sanitized output. The focused
regression set passed 154 tests. The managed test sandbox forbade binding a
localhost port, so the final browser leg remains an explicit CI acceptance
step, not an inferred success.

The lesson is about lifetime. An invite can establish a durable relationship
without becoming durable configuration itself. Authentication works better
when the credential lives exactly as long as the workflow that needs it—and no
longer.