Settings
The Settings page (/settings) holds two things that genuinely change how the company runs — the Feature Flags card and Transcript Retention — alongside a handful of browser-local preferences and read-only connection info.
Feature Flags
The Feature Flags card is the operator's master switchboard for the optional, default-off subsystems. Instead of hand-editing environment variables, you flip a switch here. Each row shows the subsystem's label, a one-line description of what it gates, and a toggle.
| Flag | Gates |
|---|---|
| External PR review | Discovering and reviewing inbound external/fork PRs. |
| Internal PR review | The read-only safety reviewer on internal branch PRs. |
| Web research | Letting the Board and PMs run web research. |
| Strategy engine | Generating and maintaining strategy artifacts (drives the Command Center's Strategy Signals). |
| Self-healing | Watching RoboCo's own CI and notifying you on a regression. |
| Self-heal originate | Also opening a pending fix task for a regression — needs self-healing on, and the task waits for your approval. |
| Pitch provisioning | Auto-provisioning projects from approved pitches. |
| Toolchain match | Provisioning each agent workspace with the target project's own Python and blocking gates when its tests can't run. |
| Conventions | Enforcing the per-project architectural standard (.roboco/conventions.yml). |
| Possibilities matrix | The work-already-done fast path: a dev whose task already has commits, an open PR, covered ACs, and no open findings completes in one call, with green PR CI standing in for the local gate. |
| Task & project cost budgets | A monthly per-project spend cap refuses new work-starting claims (in-flight review/doc/gate work always finishes); a per-task $ cap blocks an over-budget task mid-flight and notifies you — see Task & project cost budgets. |
| RAG auto-update | Keeping the knowledge base index refreshed automatically. |
| Transcript prune | Running the background sweep that prunes old transcripts. |
| Gateway-health recovery | Probing stale-heartbeat agents' gateway out-of-band and recycling ones whose toolchain is broken. |
| Multi-repo CI-watch | Watching each opted-in project's CI and opening one fix task when it goes red. |
| Dependency-update bot | Read-only checking whether an upgrade changes a project's lockfiles, and opening an update task when it would. |
| Environment-branch sync | Cascading each declared environment ladder downward: clean merges auto-push to non-prod rungs, conflicts open one sync PR. |
| Docs-divergence sync | Opening a docs-update task into the delivery flow when a release drifts from the docs site. |
| Gated release manager | Assessing readiness and proposing a version bump + changelog for your approval — the org proposes releases, you click publish. |
| Organizational memory | Distilling one lesson per completed task and injecting relevant lessons + playbooks into claim-time briefings. |
| Sandboxed per-agent test DB/Redis | Letting a dev/QA agent request a throwaway Postgres/Redis/Mongo sibling container on demand for an opted-in project, instead of injecting RoboCo's own production DB credentials. |
| Strict model routing | Failing closed (parking work) when an agent's assigned provider is disabled, instead of silently falling back. |
| X (Twitter) engine | Drafting release-announcement posts, held for your per-post approval — expand this row for the credentials form. |
| X mention replies | A sub-switch on top of the X engine above: also polls mentions and drafts held replies (needs a paid X API tier to read mentions). |
| X feature spotlight | Periodically investigating shipped features and drafting a held spotlight post for an under-publicized one. |
| Video engine | The motion-graphics pipeline: UX/UI devs author compositions, a sidecar renders MP4 cuts, drafts wait in your video queue — expand this row for the TikTok credentials. |
| Video on release | A sub-switch: also opens a video-authoring task when a release publishes. |
| Video on spotlight | A sub-switch: also opens a video-authoring task alongside a feature-spotlight draft. |
| Board roadmap engine | Weekly: the Product Owner proposes a themed cycle of 3-7 roadmap items for you to approve or reject individually. |
| Fable + Ponytail doctrine | Composing the behavioral doctrine layers (+ agent hooks) into every spawned agent's prompt. |
| Obsidian vault | Projecting tasks, journals, and A2A digests into a wikilinked Obsidian vault. |
| Vault intake watcher | Turning #roboco-tagged notes in the vault inbox into held board-review drafts. |
| Vault weekly report | Writing a weekly org-metrics report note into the vault. |
| Vault KB ingest | Embedding your own RoboCo/Notes/ folder so the fleet can retrieve what you write. |
| Telegram notifications | DMing you escalations and completions over Telegram — expand this row for the bot credentials. |
| Telegram inbound commands + actionable buttons | A sub-switch on top of the row above: also polls Telegram for /status, /queue, /task, and one-tap Approve/Reject/Open buttons on escalation DMs and the queue. |
Each subsystem has a full page in the optional subsystems section — what it does, the exact ROBOCO_* env var behind it, and what turning it on changes.
Three rows nest their credential form directly underneath as a collapsible, rather than living in a separate card: X (Twitter) engine expands to the four OAuth 1.0a secrets (API key, API key secret, access token, access token secret) the X engine needs to post; Video engine expands to the TikTok distribution leg's credentials; and Telegram notifications expands to a bot token and chat id. All three forms are write-only — once saved, the fields never show the stored values again, the card only ever tells you whether credentials are set (mirroring the per-project git-token card), and the secrets are Fernet-encrypted at rest and never appear in .env. Set every field in a form to save or rotate it; leave them all blank and save to clear.
Both are off by default and need a per-project opt-in to do anything. The global flag here arms the engine; you then opt each project in from its settings page → Budget & Ops card: turn on CI-watch and (optionally) name its workflow file (ci_watch_workflow, default ci.yml), and/or set the dependency-update command (dep_update_command, e.g. uv lock --upgrade / pnpm update) with optional comma-separated lockfile paths (dep_update_paths). See Autonomous maintenance.
Toggling a flag persists the choice server-side, but it does not hot-reload — the backend reads it at startup. The toast says as much: "takes effect on next restart." A flag you've never set falls back to its environment / config default. So: flip it here, then restart the orchestrator for it to take hold.
Transcript Retention
The Transcript Retention card sets how many days agent transcripts are kept before the prune sweep removes them (default 14). This is a real, server-persisted setting. It only ever prunes agent-owned transcripts — never your own Claude sessions. The sweep itself is gated by the Transcript prune feature flag above.
User Info
The User Info card is where your own display name lives — the one the header chip and the rest of the panel show instead of a hardcoded name. It's a real, server-persisted setting (ceo_name in the settings store): trimmed, non-empty, capped at 60 characters, editable inline. Agent prompts refer to "the CEO" generically regardless of what you set here, so changing it never touches agent behavior — it's purely how the panel addresses you.
GitHub App
The GitHub App card is a one-time credentials entry — the App id plus its RSA private key (PEM), both from a GitHub App you create on github.com — that unlocks a faster, token-free path for GitHub projects:
- Write-only, like every other credentials card here. Once saved, the panel only ever shows whether credentials are set, never the key itself; clearing requires an explicit confirmation.
- Unlocks the "Select repo" picker in the New Project dialog — browse the App's installations and repositories and pick one instead of typing a Git URL and pasting a personal access token by hand.
- Existing projects can bind to an installation from Edit Project too — the same picker appears there, and picking a repo stores the installation id alongside the project.
- Git operations mint a short-lived installation token for a bound project instead of using its stored PAT, attributed to the App's own bot identity in commits and PR reviews. If minting ever fails (App not configured, installation revoked, a network hiccup), git operations fall back to the project's own PAT automatically — a GitHub App hiccup never bricks a project that also has a token on file.
- Unbinding a project (clearing its installation in Edit Project) reverts it to the personal access token below, with no other change.
Unlike the rows in Feature Flags above, the GitHub App integration has no on/off switch — it's inert until you save real App credentials, then available to any project you choose to bind. It sits alongside git-token entry as an alternative auth path, not a replacement for it.
Connection Info (read-only)
This card displays the API and WebSocket base URLs the panel is using (NEXT_PUBLIC_API_URL, NEXT_PUBLIC_WS_URL) — relative by default so nginx dispatches them on a single origin. It's informational; you can't edit it here.
The browser-local preference controls
Appearance (theme, collapsed sidebar), Data & Refresh (Auto Refresh, Refresh Interval), and Notifications (Enable Notifications, Sound Alerts) all take effect immediately and persist to this browser's local storage — there is no page-level Save button; each switch/select writes through the moment you touch it. None of it is sent to the backend or synced across devices/browsers, which is the distinction that matters: Auto Refresh actually re-runs the current page's data queries on the interval you pick (the same mechanism the header's manual refresh icon triggers), and Enable Notifications / Sound Alerts actually gate the toast + chime the notifications bell fires for newly-arrived notifications. Only Feature Flags, Transcript Retention, and User Info are genuinely server-persisted settings.
AI provider configuration lives elsewhere
Choosing which model and provider backs each agent is not on this page — it's the AI Providers page (/settings/ai-providers), linked from the sidebar footer. There you set the global routing mode (Anthropic / Grok / Codex / Gemini / Kimi / Ollama / self-hosted / cost-tiered), or pin individual agents in Mix mode, and store the encrypted provider keys. See Provider routing.
Next
→ Optional subsystems for every feature flag in detail · Provider routing for the AI Providers page · Register your first project for the GitHub App vs. token choice on a per-project basis · Environment reference for the ROBOCO_* variables behind the flags.