# Per-user Linux accounts
When several people share one AgentWorks server, each person gets their own
Linux account on that machine — a "slot". Your commands and coding assistants
run as *you*, so another person's work is simply out of reach.
## How one command runs
1. Who's asking?The service looks up your slot in the admin-owned table. No slot, no run — never a silent fallback.
→
2. Switch userOne fixed launcher runs as your account. It can do nothing else.
→
3. Check the requestProgram on the allow-list? Folder inside the allowed roots? Your own terminal?
→
4. Run confinedAs you, in exactly the allowed folders, with a minimal fixed environment.
The launcher adds no privilege beyond your own account — there is nothing in
it for a compromised account to gain. The program list, folder roots, and
user-to-slot table are all owned by the administrator, so neither the service
nor any user can widen them.
## Who can reach what
Service
Verifies every caller.
Belongs to every group, so it can serve files and start launches for anyone.
Holds the credential store — no user account can read it.
Alice's slot
✓ Her own files and runs
✓ Folders explicitly shared with her
✗ Bob's files, terminals, launches
✗ Service credentials and config
Bob's slot
✓ His own files and runs
✓ Folders explicitly shared with him
✗ Alice's files, terminals, launches
✗ Service credentials and config
Shared folders are granted to a slot at launch, mirroring exactly what the
launch allows — read or read/write, per path. Everything a slot creates stays
inside its group; nothing is world-readable.
## Terminals stay apart too
Each slot gets its **own terminal server** with its own socket, so one user
can never see or type into another's panes. A router sends each terminal
command to the server owning that session; anything else goes to the
platform's own server unchanged. Terminals start with a minimal fixed
environment — no service secrets — and pasted content travels only with the
session being pasted into.
## For administrators
- Provision once as root, then add people (account + slot in one step).
Signing in never provisions anything.
- With slots on, shell commands require a folder guard — unguarded commands
are refused rather than run as the shared account.
- Freeing a slot releases the table entry; clear the slot's runtime files
before someone else reuses it.
Switches: `AGENTWORKS_SLOTS=on` (shell commands),
`AGENTWORKS_SLOT_CLI=on` (coding assistants, optionally limited to listed
people while rolling out). Hosts without slots behave exactly as before.
Related: [Provider credentials](provider_credentials.md),
[Security overview](README.md).