Run project commands and aidcx doctor in a Linux terminal. On macOS or Windows, prepare the runtime with native aidcx install, then open aidcx terminal and use a project cloned in that Linux environment. Native installation, update and uninstall remain host commands; macOS aidcx bridge also runs on the Mac.
One idea, three platforms.
Your project always runs in a Linux container under the secure runtime. What differs is where that Linux lives.
| System | Where the container runs | Managed by |
|---|---|---|
| Linux | On the host, with the secure runtime | aidcx install |
| macOS | A managed Linux virtual machine; an existing stopped machine is started, never recreated | aidcx install |
| Windows | A managed Linux environment; after native installation, open aidcx terminal and run project commands there | aidcx install |
On a Mac, a start in the managed machine also prepares the native display, and the clipboard is shared between the Mac and the Linux session as soon as the machine runs. Clear confidential text from the clipboard before the first start.
What you approve, and what is recorded.
The first executable start of a project needs --trusted. Trust is stored for that project's canonical path, and later starts run host commands, feature builds and container creation without repeated prompts. Preview modes (--dry-run, --effective) neither need nor store trust. Grant it only to a project you have reviewed. Commands are logged to an append-only audit log, which is not a complete record of every effect.
Live access, not copied tokens.
Git, Docker and Kubernetes inside the container reach the sign-ins of the computer that started it live; the stored account secrets are not copied into the container. For Kubernetes the container gets a configuration for your host's current context, with no token or private key written into it; choose the context before you start and restart after you change it. Agent CLI state is separate: it can be shared as files with --aidev. Turning sharing off with --sso off does not erase state written earlier, and deleting local files does not revoke a credential; revoke it where it was issued.
One authorized read proves it.
From inside the container, run one authorized read, such as git ls-remote against your approved origin. If it fails, see Troubleshooting. Check the result inside the selected project container.