Least access is an important security management principle, where access of credentials is limited to what they require, and not more. TaskUI may give a wide surface of execution, or may be limited to read-only or exec-only users that can only invoke something in a secured system. The barriers between container and machine can be a little bit blurred. Credential management is simplified and the SRE usability for the tool and its Claude bindings has proven to be pretty good. Integrations with Beszel give access to a deployment cluster, and even without specific automation in place it can sort of be used as a mix of terminal interface and claude prompts. It tells me I should water my plants.

This page says how the configuration of task-ui moves it between wide reach and least access: what least access means here, the decisions an operator makes and what each one opens up, and a checklist. A review follows, a tour of the features that handle identity, keys, encryption and roles: each section says what the code does, names the file that does it, and says where the protection ends. The findings table at the end lists what to fix or watch, by severity.

task-ui runs jobs from source trees as the user who asks, records each run, and hands each run the secrets and SSH keys its user and its workspace allow. task-ui works as a CI/CD system you can type into: a run is a terminal that people and agents watch, attach to and answer. It manages who may do what, which keys a run carries, and how secrets sit at rest. It does not sandbox the jobs it runs.

task-ui is a server in a container, and every run is a process in that container: bash -l, make, docker, ssh, Claude Code. A configured instance is as secure as the Linux system and the container it runs in: the mounts it gets, the daemons it reaches, the keys in its key folder, the network around it and the people who sign in. Managing its security is managing Linux security, with the same two moves:

• Limit the attack surface. Leave out the mounts, sockets and integrations the jobs don't need, scope keys and secrets to the runs that use them, and grant each user the narrowest role.
• Block access. A policy deny, a folder limit or an allow list removes a path; an instance of its own for each trust boundary removes every path between them.

Admin is root inside task-ui. An admin passes every permission check, sees every folder, opens @shell and @claude, reads and rotates every key, and edits users and policies. Anyone who holds admin credentials, a password, a session or an MCP token of an admin, can act anywhere in the system and can disrupt task-ui itself: end runs, rotate or delete keys, delete users, projects and workspaces, or stop the container through the docker socket. Guard an admin account as you guard a root login on the host.

Least access grants each credential the permissions its work needs and no more. A credential in task-ui is a user: a password, a session or an MCP token. What it may do is its role, its own policy on top of the role, the folders an admin limits it to, and the allow lists of folders and jobs (see Roles and policies). The default roles are a starting point to narrow: the viewer role starts with edit and delete on notes, workflows and schedules.

What the profiles leave open:

• Read-only is not blind. A viewer sees what a run prints, live and in its recording: a secret a job echoes, and an admin's @shell in a folder the viewer sees (see Terminals). The file preview serves any file of a folder the viewer sees, an imported env file at a path that doesn't start with a dot included (see the findings). The folder limit is what keeps a viewer out.
• Exec-only holds while the code holds. run on a folder whose atkins.yml, Taskfile.yml, Makefile or scripts/* the user can change through git is a command of their choosing. A job's allow list narrows that job alone: ./<path>, any executable file of the folder, and @skill:<job>, an atkins skill that applies there, run under the folder's allow list (folder/folder_path.go, FileJob; folder/skill.go, SkillJob). Name in the folder's allow list only those who may run every one of them.
• Least access costs reach. Without admin and prompt/edit a user can't look around in a terminal or ask Claude; without run on a folder they can't start its jobs; without the Claude Code integration, docker or Beszel, no run builds images, asks Claude or reaches the inventory. Each decision names what its less secure setting enables, which the more secure one forgoes.

Each row is a choice an operator makes. Default says where the image, the compose files or the database start: on in the compose files (docker/docker-compose.yml in this repository and malta/dockerfiles/task/compose.yml in production), built in to the image or the code, default for a setting with a starting value, or opt-in, off until someone turns it on.

• Admins are people you trust with the host; each admin signs in with their own account (D2).
• prompt/edit, hosts, project/edit and workspace/edit go only to people trusted with the host (D10, D8, D19).
• Runners run folders whose code they cannot change, or you trust them with the host; a folder's allow list names only those who may run every job, file and skill job of it (Least access).
• Viewers that should only read have denies on the edit and delete rules of notes, workflows and schedules, and folder limits (D14).
• The compose file mounts the docker socket only where jobs build or deploy; otherwise a dind sidecar, a socket proxy, or no docker (D1).
• The container runs on a bridge network behind the TLS proxy (D3).
• The compose file mounts registry logins and Claude Code's settings only where jobs need them (D4).
• Parent environment is None or Auto; SECRETSMANAGER_KEY and the like live in scoped secrets that scripts read with task-ui get-secret (D5).
• /keys/known_hosts holds the git remotes and inventory hosts before the first run (D6).
• Each SSH key links to the roles and users that need it; the git key exists; no production key goes to a role it doesn't need (D7).
• Beszel, when on, signs in as a read-only user, and hosts stays with admins (D8).
• The Claude Code integration's Who names the agent user and the roles that use Claude (D9).
• Each MCP agent user is an account of its own, with only what the agent needs, and its token rotates within 30 days (D11, D18).
• No private key leaves but inside an admin's export bundle (D12, D19); input stays with admins (D13).
• Data retention fits what the jobs print and how far back the history needs to reach; jobs do not echo secrets (D15).
• Each variable's scope is all or the workspace that uses it (D16).
• An env entry, whose value the Secrets page shows, holds nothing that needs keeping out of the pages; that belongs in a secret (D17).
• Backups of the database live outside the data folder, 0700; a copy of the database and /keys together opens every secret. No backup off the host holds both.
• Workspace exports use a long passphrase; delete the file after the import (D19).
• TASK_UI_AUTOLOGIN is unset (D22).
• /login has a rate limit at the proxy (see the findings).

task-ui serves two jobs: development, where people and agents work in checkouts with the tools of a full machine at hand, and the orchestration of restricted production environments, where task-ui holds the keys and credentials and the people who use it hold roles. The first wants reach; the second wants control over who reaches what. The image chooses reach and draws the line at who may run code.

What task-ui trusts:

• The host. The host's root reads the data and key folders, the database and the recordings.
• The container. task-ui and every run share one container and one OS user, root: the image sets no USER (malta/dockerfiles/task/Dockerfile).
• Admins. An admin passes every permission check (permission/set.go, decide), sees every folder and runs every job.

What the image grants by design (malta/dockerfiles/task/compose.yml):

• /var/run/docker.sock, the host's docker daemon, for jobs to build and push images and start containers;
• /keys, every private key of the instance, encryption key included;
• /root/.docker, the registry logins jobs push with;
• /root/.claude, Claude Code's settings and sessions for every user;
• SECRETSMANAGER_KEY in the server's environment, which every run gets while Parent environment is All (runner/environment.go).

The consequence: anyone who can make task-ui run a command of their choosing is root on the host, through docker run -v /:/host, and can read every key and every secret of the instance. A user without admin can still run a command of their choosing. Each of these does it, in the container or, for hosts, on the inventory's hosts:

Grant these permissions only to people you would trust with root on the host. Viewers watch and read; runners on folders whose code they cannot change start what others wrote. Where people of different trust share one host, run one instance per trust boundary, and keep production keys on an instance that only its operators reach.

Who may sign in is the password file, .htpasswd in the data directory, bcrypt hashes only (access/htpasswd.go, access/password.go). task-ui backup <user> makes ten single-use backup passwords of about 59 bits each, of which the database keeps only the hashes (access/backup_passwords.go).

A sign in issues a session cookie: 256 random bits, HttpOnly, SameSite=Strict, Secure behind TLS or X-Forwarded-Proto: https (access/guard.go, SetCookie). The database keeps its SHA-256 hash, the user and the expiry, TASK_UI_SESSION_TTL, 12 hours by default (access/session.go). A new password or the user's removal ends their sessions. Requests that change state from another site fail the origin check (access/handler.go, SameOrigin), and the run window's websocket refuses a foreign Origin (api/attach.go).

TASK_UI_AUTOLOGIN signs every request in as one user with no password. It exists for development and the screenshot scripts; production leaves it unset.

A user is an admin, a runner or a viewer (model/user.go). What a role may do is a policy: one entry per rule, allow, deny or nothing, which inherits. A user's own policy sits on top of the role's (permission/set.go, decide):

1. an admin may do everything, with any policy;
2. the user's own entry, when it has one, decides;
3. else the role's entry decides; nothing means no.

A section's all entry stands for its rules, and a deny on all denies a rule even where an allow on that rule allows it (permission/policy.go, Effect). No section adds a rule of its own: a saved entry for key/read, from before private keys stopped leaving, has no effect, since no check names it.

The rules live in one file, config/permissions.yml: view, edit, delete for each section (workspaces, projects, notes, prompts, workflows, schedules, artifacts, secrets, instance keys, integrations, inventory, users), and four application rules, run, shell, hosts and input. go run ./internal/cmd/rulelint fails the build when a check names a rule the file lacks, or a rule of the file goes unchecked. The matrix on Settings, Permissions is the whole list.

By default (schema/permission_policy.up.sql) a runner may run, and view, edit and delete notes, workflows and schedules, view the artifacts and the inventory, and write the artifact tree; a viewer the same without run and without writing artifacts. Neither holds shell, hosts, input, prompt/edit or any key, secret, project or workspace rule. The claude user holds run, notes and prompts in its own policy.

On top of the rules, an admin may limit a user to some folders, and a folder or a job may carry an allow list of users and roles (permission/set.go, Run). A schedule runs as its maker; only an admin picks another user, who must be able to run the job (api/schedule.go, runAs). A user with user/edit changes policies only when the role grants it: task-ui reads that right from the role alone (api/permission.go).

An admin turns on MCP agent user; a user then makes, rotates and turns off their own token, and the token shows once, in the response that makes it (api/user_mcp.go). /api/mcp refuses a user without the flag unless a run token signed the request in (access/handler.go, RequireMCP).

A run token exists for @claude-prompt and @claude-note runs. The board mints it at start, writes it into an MCP configuration file in a 0700 directory of its own, and revokes it and removes the directory when the run ends (note/board_mcp.go). It signs in as the run's user with only that user's permissions. It cannot start a prompt: POST /api/prompts answers 409 to it (api/prompt.go). A Claude run does not spawn more Claude runs.

A window on a run shows output to everyone who may see the run. Whether it types depends on the job:

• an interactive job, @shell, @claude or a job marked interactive, takes keystrokes from every window whose user may run that job (api/attach.go, ReadOnly: !canRun): any admin for @shell and @claude, any runner the allow lists name for a job marked interactive;
• a job that takes no input types only after Take input, which takes the input permission, which only admins hold by default (api/attach.go, takesInput).

Every key lives in one folder, /keys in the image (TASK_UI_SSH_DIR), 0700, each file 0600, as <name>.key and <name>.pub (keystore/local.go, write). The name ends in the algorithm and size, such as deploy_rsa4096. The database says what each key is for, its scope (the instance or a workspace) and whose runs get it. The page is Settings, Keys (/settings/keys); the API is /api/keys.

A key has one of two purposes (keystore/local.go, ErrPurpose):

• encrypt: the instance's encryption key, one per instance, which encrypts every secret. task-ui makes it at the first start when the instance has none, as task_encryption_ed25519. A scope holds one encryption key (keystore/local.go, free).
• ssh: keys that authenticate runs, git and the inventory to hosts and remotes. A workspace holds any number for its own runs.

task-ui signs nothing with an instance key: there is no signing purpose. A job may still use a key from its agent to sign, such as a git commit with gpg.format ssh; that is the job's choice.

Rotate key writes new material of the same algorithm and size under the key's name and moves the old pair to backup/<name>.key and .pub (keystore/local_rotate.go). The key's row shows BACKUP ACTIVE: backup/<name> while the backup exists, and both serve:

• the encryption key decrypts with the new key and then the backup, and the rotation re-encrypts every secret for the new key;
• an SSH key goes into an agent with its backup after it. A host that knows only the old public key still lets the run in.

A key keeps one backup. While it has one, Rotate key answers 409; an admin adds the new public key where it belongs, then deletes the backup, and the key rotates again.

A key either encrypts secrets or authenticates SSH, never both, and the folder holds a key material once, by its fingerprint: an upload of material it already holds, under any name or purpose, answers 409 (keystore/local.go, add). From there:

• no encryption key goes into a run's agent, git's ssh command, a link or the inventory's logins (keystore/local_runs.go, AgentKeys refuses one with ErrNotSSH);
• no SSH key is an age recipient or opens a secret (secret/vault.go);
• no route hands out a private key of either kind (see Private keys never leave), and a workspace export leaves encryption keys out (keystore/bundle.go).

This limits the blast radius. A leaked deploy key opens the hosts that trust it and no secret; a leaked encryption key opens the database's secrets and no host.

An SSH key links to roles and users (Settings, Keys, Who gets it; PUT /api/keys/{name}). A run gets (keystore/local_runs.go, ForRun):

• the instance SSH keys linked to the run's role or to its user;
• its workspace's SSH keys linked the same way, or linked to nobody, which goes to every run of the workspace.

An instance key linked to nobody stays with the instance: the inventory signs in with it, runs don't. A host command, @host:<name> or @host:*, gets every instance SSH key besides, as the inventory does (runner/keys.go). One SSH key may be the git key, which task-ui's own clones and pulls use (keystore/local_git.go). A typical layout: the git key and a deploy key linked to the admin role, a key per user for their own hosts, and a workspace build key linked to nobody.

A run gets its keys in an ssh agent of its own, served from memory on a socket, and SSH_AUTH_SOCK names it (runner/manager.go, execute; sshagent/agent.go). A run with no keys gets an empty SSH_AUTH_SOCK, never the server's agent. The terminal's first line names the keys: $ ssh-agent: deploy_rsa4096, task_ssh_ed25519, or (none). The agent closes when the run ends.

The agent decides which keys task-ui loads for a run. It does not decide what a run can reach: a job runs as root beside /keys and reads every key file there. Links are a statement of intent and keep honest jobs to their keys; they are not a wall against a job that goes looking.

Every ssh in the image accepts a host's key on first contact and keeps it in /keys/known_hosts: StrictHostKeyChecking accept-new in /etc/ssh/ssh_config.d/task-ui.conf (Dockerfile), in git's ssh command (git/git.go) and in the inventory's probe (sshprobe/prober.go). No run waits on a "continue connecting?" question, and a key that changes later fails the connection. The cost is trust on first use: whoever answers for a host the first time is the host from then on. Seed known_hosts with the keys of the git remotes and the inventory before the first run reaches them.

Two readers open a private key: the ssh agent of a run, which gets the keys the run's links name ($ ssh-agent: ... on the terminal's first line), and task-ui itself for signing and decrypting. No API route, MCP tool or page returns a private key, encrypted or not, and no log counts reads of one: the key_read table stays in the schema, empty and unused. The one copy that leaves is inside a workspace export, for an admin alone, encrypted to the bundle's passphrase (Workspace export).

A variable is a name and a value that runs get as an environment variable. Each is a secret or an env entry: task-ui encrypts both with age to the instance's encryption key, an ed25519 or RSA key used through agessh, and stores them armored (secret/vault.go; secret/store.go, Set, SetEnv). The public key encrypts; the private key in /keys decrypts. A copy of the database alone opens nothing; a copy of the database and /keys opens everything. Rotating the encryption key re-encrypts every variable (secret/store.go, Rekey). A secret's value is never shown after a save; Settings, Secrets lists an env entry's value. Anything that must stay out of the pages belongs in a secret.

A variable's scope decides which runs get it (secret/store.go, Reaching):

• all reaches every folder of every workspace, including a workspace added later;
• workspace:<name> reaches every folder of that workspace, and no folder of another workspace;
• a folder's own variable, an older scope, reaches that folder's runs, and other runs in the workspace read the workspace's variable of the same name; a run in a workspace without a variable of that name reads the one of every workspace.

The scope keeps a variable out of another workspace's environment. It does not keep it out of reach on disk: the database and the key that opens it sit beside every run.

Each run records one read per variable it gets: the variable, the run, the folder, the directory, the job and the user (runner/command.go; storage/secret_read_storage.go). Settings, Secrets shows each variable's Reads and Last read, and /settings/secrets/<id>/reads pages the log, newest first. task-ui keeps the last 1000 reads of each variable.

A run's environment is sensitive. task-ui writes neither a value nor a name of it into the run. The run's page, its output, its recording and its row hold no secret and no variable name. The only trace of which run got which secret is the read log on the secret's page, which takes secret/view. The terminal's first line names the SSH keys in the run's agent, by name; no key material and no fingerprint.

What a job prints, the recording keeps. A job that echoes a secret puts it in the recording, readable by everyone who sees the run (see Terminals).

An env entry is a variable of the same store whose value Settings, Secrets shows (is_secret false, value in the API). It reaches runs exactly as a secret does, and task-ui get-secret reads it too; the read log records it, and a job that prints one puts it in the recording. task-ui writes no dotenv file into a folder before a run: the environment is the only place a run gets these values.

Env files of older instances survive in the database, and a workspace export carries them and an import writes them back into the folders it clones (api/workspace_import.go, writeImportedEnv). A bundle is an admin's, and the path it writes is relative to the folder, with no parent reference (envfile.SafeRelative); the file preview serves a path that does not start with a dot (see the findings).

A workspace exports as <folder>.tui.age: an age file encrypted to a passphrase of at least 12 characters, through age's scrypt recipient (workspace/bundle.go). Inside are the manifest, with the workspace, its projects, its env files and its variables in plain text, and the SSH keys its runs get (workspace/manifest.go). No instance key and no encryption key goes: the importing instance encrypts the variables for its own key. The passphrase travels in a POST body, out of URLs and logs (api/workspace_export.go). Export and import are for admins alone, with or without workspace/edit: the bundle carries the workspace's secrets and SSH private keys, the one way a private key leaves task-ui, and the import writes keys into the key folder. The bundle is as strong as its passphrase: no file task-ui produces needs more care.

Every run is a terminal on the server, a PTY, that belongs to no browser window (runner/). The dashboard shows each terminal in progress as a tile with its live screen; a click opens a window on it, and /api/runs/{id}/frame.svg and frame.txt serve the screen as a picture or text. Together this works as a shared remote desktop for terminals: an admin opens @shell in a folder, a colleague attaches and sees the same screen, and an agent's run shows next to it.

Identity carries into the terminal:

• @shell, a login shell, and @claude, Claude Code in a terminal, run for admins alone: their allow list names the admin role, and the task-ui checks the shell permission besides (folder/shell.go, api/target.go, canRun); @claude also takes a Claude token from the Claude Code integration.
• The shell runs with the opener's SSH keys in its agent, and with TASK_UI_USER, TASK_UI_ROLE and TASK_UI_PERMISSIONS in its environment (runner/command.go).
• Every run records who started it; schedules run as their user.

What a terminal shows, everyone who sees the run sees:

• a run shows to every user who sees its folder (model/user.go, SeesRun), viewers included: a viewer watches an admin's @shell in that folder as it happens;
• an interactive run takes keystrokes from every window whose user may run the job (see Interactive input);
• the recording is an asciicast of the terminal's output (recording/recorder.go): what the screen showed, keystrokes included as the terminal echoes them, a password typed at a prompt that does not echo left out. Data retention keeps recordings and runs 31 days by default (retention/settings.go); a run's row stays after its recording goes, until run history lets it go.

A secret printed in a shell, a token pasted on a command line, a cat .env: each lands in the recording and on the screens of everyone attached.

Every page carries a content security policy (markdown/markdown.go, CSP; frontend/frontend.go, policy): scripts, styles, fonts and images come from task-ui itself, an image may be inline as a data URL, forms post to task-ui alone, and no other site shows a page in a frame. Inline styles stay allowed, as the templates size bars with style attributes and the terminal writes its own. A note, a reply, a prompt's answer, a run's summary and a markdown file of a checkout or of the artifacts render through the same renderer: raw HTML shows as text, links keep to safe schemes, and an image from elsewhere shows as a link to it. No reader's browser fetches it, and no host outside learns who reads what, and when. A file a run or a checkout wrote, served on its own, carries a stricter policy still: no script, in a sandbox (frontend/artifact.go, serveFile).

A workspace is a directory under the root with a home, the checkout of its home repository or an empty directory, and a src of projects, with its own SSH keys and its own secrets (Workspaces). Every run in a workspace gets the home as HOME, always, the server's HOME never: atkins finds the workspace's skills there, bash -l reads its .profile, and Claude Code reads its CLAUDE.md (runner/home.go, HomeEnv). So whoever commits to the workspace's home repository controls that workspace's runs. What the server keeps in its own HOME stays in use through four variables pointed back at it, each set only when the server does not set it: the registry logins (DOCKER_CONFIG), Claude Code's settings (CLAUDE_CONFIG_DIR), the cache (XDG_CACHE_HOME) and GOPATH. atkins' history, ATKINS_DB, is the home's, with the instance's copy as a mirror it writes and never reads. ssh reads ~/.ssh from the password database, and its configuration stays the server's.

What a workspace keeps apart: which variables enter a run's environment and which SSH keys enter its agent. What it does not keep apart: the OS user, the container, the key folder, the database, every checkout under the root, the registry logins and Claude Code's sessions. A job someone in one workspace can change can read another workspace's secrets. Workspaces organise trusted people; they do not separate untrusted ones.

Claude Code runs inside task-ui in three ways: @claude, an interactive terminal; @claude-prompt, a prompt from a page, the API or ask_prompt; and @claude-note, a note to the agent. All three start Claude Code with --dangerously-skip-permissions (agent/shell.go, agent/claude.go): Claude runs commands without asking. What bounds it:

• The user. A prompt runs as the asking user, with that user's folders, keys and secrets. Claude's system prompt names the user, the role and the permissions (agent/claude.go, context), and its MCP connection is the run token, with that user's permissions.
• The token. The run token lives for the run, signs in as one user, and cannot start another prompt.
• The container. Claude runs as root in the task container, with docker.sock. Inside the container only the user's own keys and secrets bound it, and those only by convention (see Stance).

The MCP server at /api/mcp serves its tools by calling the JSON API in process as the token's user (mcp/server.go), and a tool checks what the page checks. The tools: whoami, list_jobs, list_workflows, run_job, run_workflow, get_workflow, create_workflow, update_workflow, list_runs, get_run, list_workflow_runs, list_notes, note_comment, post_note, ask_prompt, list_artifacts, read_artifact and write_artifact. run_job opens @shell or @claude for admins alone, and cannot start @claude-prompt or @claude-note, which start from their own routes (MCP). A refused call names the permission it needs.

An agent outside task-ui, such as Claude Code on a laptop, holds an MCP token for 30 days. Treat it as the user's password: a dedicated user with only the permissions the agent needs, run on chosen folders and notes, is the usual setup.

Contents · Running the server · API