per_user_linux_accounts

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, Security overview.