App Settings

Your settings live on two pages, split by how far they reach:

• Account (/account) — you: theme, timezone, auto-update, your profile, your devices, your git accounts, your membership. These follow you into every workspace, which is why the page hangs off the avatar in the sidebar's header rather than off any workspace.
• Workspace settings (/workspace/settings) — everything scoped to the workspace you're currently in: automation, project access, git and branching, AI models, access control, storage. Reached from Settings in the workspace switcher. Switch workspace and you're looking at a different set.

Workspace settings holds two tiers of the same field set, and an Editing: Mine | Workspace toggle at the top picks which one you are writing:

• Mine — your own defaults for your runs in this workspace. Nothing you set here is visible to, or affects, anyone else.
• Workspace — what the workspace answers for everyone in it. Owners and managers write it; everyone else reads it. See Workspaces → Workspace Settings.

They are one page rather than two because they are adjacent rungs of one cascade: the value you override under Mine is the one Workspace is answering, and it is a click away instead of a page away. Flipping the toggle keeps you on the tab you were reading wherever both tiers have it, and falls back to the first tab the new tier does have when they don't — a personal setting has no answer for a project's repository access, and the workspace's encryption keys are not a personal setting.

The split between the two pages follows the storage: the Account page writes preferences that belong to your account and are read wherever you sign in, while workspace settings writes rows inside one workspace's own database. That's why theme is on one page and your default branch strategy is on the other.

Linking into it

The page's address carries where you are in it, so a link can name a tab, a panel, and which tier to open on:

/workspace/settings?scope=<member|workspace>&tab=<tab>&sub=<panel>

scope is the tier — member for Mine, workspace for Workspace — and an address that names none opens on Workspace. tab and sub name the section and the panel inside it. Anything the active tier can't show falls back to the first thing it can, rather than to an empty panel, and the address keeps what you asked for — so flipping the toggle to the tier that does have it takes you straight there. This is how the app's own shortcuts work: a run blocked on a model with no key behind it sends you to your own AI Models → Providers, not to the workspace's.

Account: General Tab

The General tab is split into sub-tabs: Appearance (theme), Timezone, Performance, and Updates.

Theme

Seven theme options:

Timezone

Affects:

• Which day Recaps opens on, and how recap dates group (daily / weekly / monthly / etc.)
• Metrics dashboard time axes, and the day buckets behind the Daily Cost Trend and AI-usage trend charts
• The window a Metrics period preset covers — 30d ends on your current day, not your machine's
• The clock on a chat wake timer ("Waiting until 2:07pm")
• Timestamp displays throughout the UI

Timestamps are stored UTC server-side — timezone conversion happens at display time. Set Auto to use the browser's detected timezone.

Performance

Build & test concurrency — how much heavy compute the build/test throttle allows at once on this machine. Default is 6 (allowed range 4–32). Agents run builds, full test suites, and typechecks through a shared budget so they don't thrash your machine: one full build runs at a time by default while lighter checks (a single typecheck, one test, a format) ride alongside it. Raise it on a many-core machine to let more heavy checks overlap; the floor keeps at least one full build able to run. Changing it applies immediately — no restart needed.

It is per-machine, full stop: each machine you use keeps its own number, tuned to its own cores, and changing it on one machine never touches another.

There is no setting for how many AI tasks run at once, and there is nothing to tune. Agent runs spend nearly all of their time waiting on a reply rather than working your CPU, so Trinity starts every task you queue, across every project, and lets your AI provider's own rate limit do the pacing: hit one and the run shows a short cooldown and picks up where it left off instead of the queue stalling. A run that hands work off to background agents suspends itself while they work — it holds nothing open — and resumes when they're done, so a big fan-out costs no more than the work actually being done. Story execution is separate again and uses its own per-release worker pool.

Auto-Update

Trinity checks for updates every 4 hours:

• Available update → pill in the title bar with an Update Trinity button
• Auto-Update (on by default) → install automatically once Trinity is idle (no jobs running or claimed); turn it off to install updates only when you click Update Trinity
• Trinity never interrupts an active run — if jobs are in-flight it waits for them to finish
• Manual install respects the same rule: if execution is active you'll see a "waiting for execution" warning
• After an update, Trinity shows that version's highlights once, in a What's new card with a link to the full changelog. Each version's card shows once per machine, a fresh install skips it, and going back to an earlier version doesn't bring it back

Account: Profile Tab

The Profile tab is where you manage your account identity. It's split into sub-tabs: Details, Avatar, Handle, Password, and Devices.

Details

Edit the display name shown across Trinity and the website (the user menu, activity, comments, and your avatar's initials fallback). Your email is shown read-only — it can't be changed.

Below it, What You Do holds the professions you state about yourself — one row per craft, each with the level you work at (new, mid, or senior), from the same roster the sign-in question uses. Add a row, remove one, change a level, then click Save. It belongs to your account, not a device or a project, so one answer applies in every project, workspace, and thread. Trinity's agents read it as context about whoever is talking and pitch explanations accordingly; it never changes what's offered to you, and an empty list is a perfectly good answer.

Avatar

Upload a picture (you crop it to a square before it's saved) or Remove it to fall back to the picture from your sign-in provider — and if you have neither, your initials. Your avatar shows everywhere your name appears, across Trinity and the website (activity, comments, the people in a shared conversation). It belongs to your account, not a single project.

Handle

Pick a unique @handle for invites and identification. As you type, Trinity checks availability and only enables Update Handle for a well-formed, free handle (3–30 lowercase letters, numbers, and hyphens; no leading, trailing, or consecutive hyphens). Changing it updates everywhere your handle appears, so the people you work with see it right away.

Password

Set a new password (at least 8 characters). You enter your current password to confirm it's you; a wrong current password is rejected with an error.

Devices

Secrets in Trinity are end-to-end encrypted: encryption keys are generated and held on your devices, and the server only ever stores ciphertext. The Devices sub-tab lists every machine enrolled on your account and is where you approve, revoke, and recover them.

Each row shows the device's name, platform, last-seen time, and a status badge — Active, Pending approval, Revoked, or No keys.

Approving a new device. Signing in on a new machine enrolls it as pending: it can't read encrypted secrets until an existing device approves it. Open this tab on a device you already use and click Approve. Approval is your call alone — a workspace owner or manager can never approve a device on your behalf.

Recovery code. Your first device generates a one-time 12-word recovery code, displayed here until you confirm you've saved it. Store it somewhere safe (a password manager works well). If you ever lose every approved device, sign in on a new machine and use Restore with your recovery code on the pending device to get your keys back without an approver.

Revoking a device. Click Revoke on a lost or retired device to permanently bar it from receiving keys. A lost device's keys stay sealed in its OS keychain, so revocation alone is normally enough. If you believe the device may be compromised, check also rotate my keys in the confirmation dialog — every encryption key you hold is reissued, and anything written from that point on is unreadable with the old keys.

Device-change alerts. If new entries appear on your account's device list, Trinity shows an alert prompting you to review the list and revoke anything you don't recognize.

Account: Git Accounts Tab

The git accounts connected on this device (GitHub, GitLab, self-hosted Gitea/Forgejo), with a per-host default radio choosing which account Trinity acts as on each host. Connect another account with a token or a guided CLI sign-in — or, for GitHub, Sign in with GitHub (an OAuth device flow: Trinity shows a short code, you enter it on GitHub to authorize Trinity, then Trinity finishes connecting). You can also import the accounts your CLIs already hold, and use Set up here for accounts connected on another machine whose credential isn't on this device yet. For Bitbucket and Forgejo/Gitea, each account also carries a commit email (set it from the account's menu) that stamps the commits Trinity makes — see Commit email per account. A Forgejo/Gitea access token needs the write:issue scope beside write:repository and read:user, so Trinity can read and file issues there.

What Each Git Host Supports

What Trinity can do on a repo depends on the host it lives on. Pull requests work on every host; issues do not.

Trinity files every story as an issue on a host that has a tracker; on one without, the story's plan goes in the pull request description. Trinity also posts the documenter's close-out as a comment on a Bitbucket pull request, and the Architect tells you it can't work issues there rather than half-doing it.

A repository destination is not here: where new repos get created is one answer per workspace, so it lives under Workspace → Git & Branching → Destination and has no personal tier at all.

Account: Membership Tab

While the closed beta runs this tab is privacy controls alone. An approved account is comped for as long as the beta lasts, so there's no subscription to report and no seat to sponsor — the Subscription and Seats sub-tabs aren't there, and a link that names one lands on Privacy instead.

Once the beta opens, the tab carries three sub-tabs:

• Subscription — status (active / trialing / comp / etc.) and trial countdown
• Seats — sponsored-seat management (owners can sponsor other users; recipients accept/decline from their Inbox)
• Privacy — privacy controls

(Your storage quota and usage live under Workspace → Access Control → Storage.)

Workspace Settings: Editing Mine

Everything under Mine is your answer for the workspace you're in. A field you leave alone shows a workspace badge and takes the workspace's own value; setting it overrides that for your runs only, and Clear removes your own value so the setting falls back to the next layer down — the workspace's value (or, for a project override, the project's). Nothing you set here is visible to, or affects, anyone else.

Automation

Your defaults for every project in this workspace, unless the project overrides them. Full cascade: Trinity's defaults → workspace settings → my workspace settings → project settings → my project overrides → entity (story/release) → job. These sit at the "my workspace settings" layer.

Toggles available:

• Reviewers per Story — how many reviewers audit each story; a number from 1 to 10, and a story can set its own on its page. A quality checkpoint reads the same number as its audit → fix iterations
• Auto-merge — merge PRs automatically when checks pass
• Squash merge — squash commits on merge
• Delete branch after merge — clean up story branches after merging
• Skip asset check — bypass the missing_assets gate
• Skip business details check — bypass the missing_business_details gate
• Delete release branch after merge — clean up release branches
• Auto-approve quality checkpoints — run the full checkpoint pipeline but skip the human gate
• Auto-approve technology deviations — skip the approval gate when the analyst proposes a technology deviation (the deviation still surfaces in the PR)

One more setting sits below the toggles, and it is a choice rather than a switch:

• Pull requests without verified checks — Ask me pauses a merge whose pull request has no checks, or checks that finished without passing, at the Checks Unverified gate; Merge without them goes ahead without asking. A failing check always stops the merge

Git & Branching

Panels Branching, Releases, Promotion — your own branching, release, and promotion defaults for new projects in this workspace. Where new repositories get created is one answer per workspace, so Destination appears only under Workspace. Per-project overrides live in Project Settings → Git; see Project Settings for the full shape of branching configuration.

AI Models

Your own models per tier for this workspace, over whatever the workspace itself set.

You can't assign a model with a lower intelligence level than the tier requires — e.g., you can pick an Opus-class model for the Standard tier but not a Haiku-class model for Reasoning. Frontier has a configurable default row like the other three, but nothing routes there on its own — it's the only tier you have to opt into by hand.

Providers

Trinity supports models from Anthropic, DeepSeek, Moonshot, Z.ai, Qwen, Xiaomi, OpenAI (via Codex), xAI, Sakana, and a local Ollama runtime. Configure each provider's API key in the Providers panel. Provider keys are secrets held per person, so Providers appears only under Mine.

See AI Model Configuration for the deeper tier explanation.

Storage

Your own S3 credentials for this workspace, used by projects on BYO S3 storage. A project that carries its own credentials uses those instead. Which backend new projects default to is a workspace-wide choice and lives under Workspace → Access Control → Storage.

How Settings Sync

Every setting on both pages lives server-side and syncs to every device signed into your account. The desktop reads and writes them over HTTP — there's no local override or cached copy of your preferences. The difference is reach, not storage location: Account settings are read in every workspace, while both tiers of workspace settings are read only in the workspace they were written in.

Exception: a small local cache holds one non-user-facing value — your cached worker-count default — not one of your preferences. Build & test concurrency is deliberately per-machine and never syncs.

Data & Disk Layout

Trinity's desktop stores only machine-local state. Project data (PRDs, stories, tags, stack, activity, recaps, releases, assets, secrets, member + workspace settings, etc.) lives in trinityailabs.com's Turso DBs and is reached over HTTP. There is no sync DB on the desktop.

What lives in ~/.trinity/ on disk:

~/.trinity/
├── trinity-{slot}.db          Machine-local SQLite — worktrees, workers, coordinator,
│                              chat sessions, tasks, device_config, local_project_bindings,
│                              local_job_state. Never syncs.
├── accounts-{slot}/           Account state ({slot} = dev | prod)
│   ├── users/                 Your Trinity accounts — one folder per signed-in account
│   │   └── {userId}/
│   │       ├── auth.json      Durable session token
│   │       ├── manifest.json  Workspace manifest cache
│   │       ├── enrollment-status.json  Last device-key setup failure
│   │       ├── e2e-chain-pins.json     Trusted device-chain pins
│   │       └── assets/        Library files that belong to no project
│   └── git/                   Your connected Git accounts — one folder per account
│       └── {gitAccountId}/
│           ├── ssh/           Trinity-managed SSH keys for this account
│           ├── known_hosts    Pinned host keys Trinity verifies against
│           ├── tokens/        Git provider tokens
│           └── askpass-https.sh  HTTPS credential helper script
├── active-account-{slot}.json Pointer to the active account
└── projects/                  Trinity-owned clones + git worktrees for parallel execution

Two different things live under accounts-{slot}/: users/ is your Trinity sign-in, and git/ is the keys and tokens for the Git accounts you've connected. They're separate folders because they're keyed by different ids — removing one doesn't touch the other.

The {slot} suffix (dev | prod) keeps development and production state isolated. Signing into localhost or dev.trinityailabs.com uses -dev; signing into www.trinityailabs.com uses -prod.

Reset

If you need to start fresh:

1. Stop all execution
2. Delete ~/.trinity/trinity-{slot}.db. To sign out as well, delete the whole accounts-{slot}/ folder — deleting only accounts-{slot}/users/ signs you out but leaves your connected Git accounts' SSH keys and tokens on disk in accounts-{slot}/git/
3. Restart Trinity — the local DB runs its migrations and regenerates empty; auth re-mints on next sign-in, and any Git accounts you deleted come back through the connect flow; project data is untouched because it lives on the server

Refresh Intervals

Most data updates in real time via a WebSocket push channel as events fire on the server:

• Run page — live updates as stories progress
• Metrics dashboard and move requests — push-driven via the WebSocket channel; a 30-second poll runs only while the channel is unavailable
• Workspace members and invites — refreshed by a 5-minute poll
• Presence — push-driven (no polling)
• Release selector — refreshed on release transitions

The push channel is on by default in production. You can toggle it via the browser console:

localStorage.setItem('trinity_flags', JSON.stringify({ use_ws_doorbells: false }));

Then refresh — Trinity falls back to polling every 30 seconds for run, metrics, notifications and tasks.

Keyboard Shortcuts

Trinity uses standard web-app navigation. No custom keybindings are user-configurable today — navigation is through the sidebar and in-page controls.

Resource Usage

Trinity runs a small bundled server alongside the desktop app, plus a local SQLite for machine-only state. Resource usage scales with:

• Number of parallel workers (each worker spawns an agent harness process)
• Active project size (worktree files on disk)
• Agent operations in flight

For most projects, Trinity runs comfortably on a standard development machine.