Questpie Autopilot Work Machine

The Work Machine runs Questpie Autopilot Agents on your macOS or Linux computer. It uses your existing native Codex or Claude login. It does not ask for provider API keys and does not copy provider sessions to the Autopilot server.

Connect and run

bunx @questpie/[email protected] login \
  --url https://autopilot.questpie.com

bunx @questpie/[email protected] start

login opens or prints the browser approval link. start stays in the foreground. Press Ctrl+C or run questpie-work-machine stop from another terminal for graceful shutdown. Run status to inspect safe local connection state. Every command supports --help with a full option reference and worked examples, for example questpie-work-machine login --help.

Multiple companies on one machine (--profile)

One Work Machine enrollment belongs to one Company. To run daemons for more than one Company on the same OS user, add --profile <name> to every command. A profile gets its own isolated state directory, worker home and (if installed) background service, so profiles never share files or provider sessions with each other. The default profile (used when --profile is omitted) keeps the exact directory and service name of every install made before profiles existed, so an existing enrollment keeps working untouched after upgrading.

bunx @questpie/[email protected] login \
  --url https://autopilot.questpie.com \
  --profile yielda \
  --name "Sales laptop"

bunx @questpie/[email protected] start --profile yielda
bunx @questpie/[email protected] status --profile yielda
bunx @questpie/[email protected] service install --profile yielda

status also lists the names of any other profiles already enrolled on the machine. Running login again for a profile that is already connected -- to the same Autopilot server -- prints that existing connection plus a --profile <name> hint instead of a silent "Work Machine connected."; running it against a different server fails outright with a message naming the existing connection and pointing at --profile <name> for adding another company. Either way, a second login never leaves you guessing which company this machine, or this profile, is talking to.

To forget a profile's local state on this machine (this does not revoke the enrollment on the Autopilot server -- do that there first if needed), run questpie-work-machine logout --profile yielda --force. Without --force it only previews what would be removed. --force also uninstalls any background service installed for that profile before removing its state, so the removed directory is never still referenced by an installed unit.

Run as a background service

After login, install an unprivileged user service:

bunx @questpie/[email protected] service install

On macOS, the LaunchAgent starts after user login and restarts after a failure. On Linux, the systemd user service starts with the user session. To also start it at boot before interactive login, use service install --linger. Use service status, restart, stop, or uninstall to manage it. Re-run service install after upgrading the package so the service uses the new CLI. Installation keeps an exact package copy under the private Work Machine state directory, so the service does not depend on a temporary bunx cache after restart or reboot.

service install --profile <name> installs the service under a distinct, profile-suffixed name (a .service unit suffixed -<name> on Linux, a .plist label suffixed .<name> on macOS), so more than one company's daemon can run as a background service on the same machine at once. The default profile's service keeps its original unsuffixed name.

The process runs without elevated privileges. The operating-system user and the native provider tools control local files, shell access and provider sessions.

An enrolled Agent can use the shell, files and native provider tools with the same access as the operating-system user who starts this process. Run it only in the user account and environment where that access is intended.

One Work Machine enrollment belongs to one Company. Within that Company, every Agent routed to the machine uses the same operating-system account and the same native Codex or Claude login. Worker Home session directories prevent accidental resume into another Agent Session, but they are not a security boundary. The allow-all shell can read, alter or exfiltrate anything accessible to the daemon user, including peer workspaces, provider profiles and Work Machine identity material. Only mutually trusted Agents may share this local Work Machine. Use a separate OS account, VM or machine when provider identities or host files must be isolated. The setup/readiness protocol does not serialize provider account names, config paths, tokens or native session credentials. Those values remain on the machine but are accessible to its workloads.