Configuration#

Every setting Prepcook keeps, grouped the way Settings groups them, with its default. Settings are stored in config.json in the app data directory (~/.local/share/prepcook on Linux, ~/Library/Application Support/prepcook on macOS), currently in its v10 shape. The Settings pages write that file; a setting marked file only has no control on a page and is changed by editing the file while Prepcook is stopped. The orchestrator re-reads its settings on every poll, so a change made in Settings applies without a restart.

Defaults below are what a new config starts with. "Unset" means the key is null or absent, and the behaviour described applies.

Orchestrator#

Settings → Orchestrator. Global values; most can be overridden per board (below).

Key	Default	What it does
`orchestrator.mode`	`off`	Enable automatic agent launches. `auto` scans the boards and runs the stages; `off` runs nothing on its own.
`orchestrator.poll_interval_secs`	`15`	Poll interval: seconds between scans.
`orchestrator.max_launches_per_tick`	`3`	Max launches per tick: new agent sessions started per scan, highest priority first.
`orchestrator.autonomy`	`off`	Autonomy mode. `full` is Prep mode: passing plans self-approve, verified fixes go to Review, approved reviews go to Shipped. `off` is Chef mode.
`orchestrator.autonomy_review_iterations`	`3`	Review-fix rounds before escalating: fix rounds before a card that keeps getting REQUEST CHANGES waits for a person. Applies in both modes.
`orchestrator.pattern_threshold`	`5`	Pattern-review threshold: linked RCAs on one graph node that file a pattern review (rca-graph.md). Older configs call it `investigation_threshold`, which is still read.
`orchestrator.default_board`	unset (the first board in `project_defaults`)	File only. The board `POST /api/cards` files into when the request names none (api.md).
`orchestrator.deployed_retention_days`	unset (off)	Auto clean-up after: days a card may sit in an older board's Close column before it moves to Clean up (a card Clean up would refuse stays). A board with Shipped is cleaned up by hand.
`orchestrator.cleanup_retention_days`	unset (keep)	Delete after: days a card may sit in Clean up before it is deleted. Cards with a pinned workspace or a takeover are kept.
`orchestrator.workspace_retention_days`	`30`	Workspace retention: days after clean-up before a workspace's records, sessions and logs are deleted. Unset keeps them.
`orchestrator.digest_at_local`	unset (off)	File only. Local `HH:MM` at which the engineers' digest is sent to each board's notification targets.
`orchestrator.eob_at_local`	unset (off)	File only. Local `HH:MM` at which each in-flight ticket gets its daily update on the tracker (working-alongside-people.md).
`orchestrator.daily_timezone`	unset (`America/Los_Angeles`)	File only. IANA zone the two times above are read in.
`orchestrator.project_defaults`	empty	Automated projects: the boards the orchestrator scans, keyed by board id, each with its repositories and overrides. A board needs at least one repository.
`orchestrator.seat_monitor`	`false`	File only. Probe the Claude subscription seat with a headless `claude -p` every six hours and notify the global notification targets when its login has expired, for a shared runner. Off, Prepcook never runs `claude` on its own; Settings → Claude → Re-check now still probes on demand.
`executor_profile`	Claude Code, default variant	Settings → Agents → Default profile (also Settings → General → Default Coding Agent): the profile every stage starts from (Agents).

Agents#

Settings → Agents. Which coding agent profile runs each orchestrator stage. A profile is an agent and an optional variant, written { "executor": "CLAUDE_CODE", "variant": "SONNET" }; the agents and their shipped variants are listed under Coding agents, and Settings → Agent profiles adds variants of your own.

Key	Default	What it does
`agents.stages.planning`	unset (`executor_profile`)	Planning: specs, RCAs and investigations, and the follow-ups that revise them.
`agents.stages.executing`	unset (`executor_profile` with the agent's economy variant: Claude Code `SONNET`)	Executing: the change, and every fix round, CI fix, rebase and merge-request description in its worktree. The economy variant applies, here and below, only when `executor_profile` names no variant (method.md).
`agents.stages.reviewing`	unset (`executor_profile` with the economy variant)	Reviewing: the independent review session. A fresh review started from a workspace defaults to it when it is set.
`agents.stages.comment_reply`	unset (`executor_profile` with the economy variant)	Comment replies: answers to comments on shipped tickets (the `comment_reply` playbook).
`agents.stages.pattern`	unset (`executor_profile` with the economy variant)	Pattern reviews: the `pattern:planning` session and the `rca_analysis` runs that link RCAs into the graph.

A stage resolves, most specific first: the board's agents.stages.<stage>, the global agents.stages.<stage>, then the stage's default built from the board's executor_profile, else the global one. A follow-up continues its session's conversation, so it can change variant but not agent: a stage moved to another agent takes effect from that stage's next new session.

Each agent's card shows whether a sign-in was found, read from the agent's own files when the page opens (nothing is probed at startup), and Test runs its command with --version for at most 10 seconds.

Ticketing#

Settings → Integrations → Ticketing. Where cards come from: a ticket tracker, or an incident tool whose open incidents become investigation cards (incidents.md). Without one no tracker is configured: every card is made on the board, the ticket pickup does not poll, and nothing is written to a ticket (method.md).

The section is ticketing. A config that still calls it tracker (and a board override called tracker or jira) is read the same way and saved as ticketing. One section serves every kind: each kind reads the fields its provider names (below), and fields that only one kind reads carry its name, so switching kinds never hands one service another's credentials.

Key	Default	What it does
`ticketing.mode`	`tickets`	Source. `tickets` takes tickets from a tracker (`jira`, `github_issues`); `incidents` takes open incidents from an incident tool (`pagerduty`) as investigation cards. A kind that does not serve the mode leaves no tracker configured, and Prepcook logs why.
`ticketing.kind`	`jira`	The provider: `jira`, `github_issues`, `pagerduty`, or `linear` (named, not implemented: every call to it says so). Its own fields are in Ticketing providers.
`ticketing.import_filter`	unset (by kind: Jira's open-sprint `To Do` tickets assigned to you, by priority; GitHub's `state:open assignee:@me`; PagerDuty's open incidents)	Import filter: the query the import dialog runs, in the provider's syntax. `{project_key}` is substituted.
`ticketing.enabled`	`false`	Pick up new tickets automatically for the board below.
`ticketing.project_id`	unset	Import into project: the board picked-up tickets land on.
`ticketing.pickup_filter`	unset (by kind: `project = {project_key} AND priority in (P0, P1) AND issuetype = Bug`; `state:open label:bug`; `status:triggered,acknowledged`)	Pickup filter: which new tickets are picked up.
`ticketing.assigned_filter`	unset (off)	Assigned pickup filter: tickets assigned to the agent's account, imported and started whatever their priority.
`ticketing.poll_secs`	`45`	Poll interval of the ticket pickup.
`ticketing.incidents.resolve_on_triage`	`false`	Resolve the incident when it is triaged (incidents mode). Off, the incident only gets the triage report as a note.
`ticketing.status_mapping.planning`	unset (`In Progress`)	Stage statuses: where a ticket moves when Plan starts (a label on GitHub Issues). Plan also assigns the ticket to the agent. Not used in incidents mode, where Plan acknowledges the incident.
`ticketing.status_mapping.executing`, `.reviewing`, `.pushed_mr`, `.done`	unset (no move)	Where a ticket moves when that stage starts. `pushed_mr` and `done` follow the card's pull request, not a column: `pushed_mr` when it opens, `done` when it merges (or, for a card that never had one, when it is cleaned up); on GitHub Issues `done` also closes the issue.
`ticketing.status_mapping.triaged`	unset (no move)	Triaged: where an investigation's ticket moves when its triage report is in; the card stays in Plan (method.md).
`ticketing.status_mapping.shipped`	`Merged`, `Deployed to Production`, `Done`	Shipped statuses: names that mean the work shipped, for reopen detection and the clean-up sweeps. On GitHub Issues a closed issue's status is its `done` label, else `Closed`.
`ticketing.blocker_priorities`	`P0`, `P1`	Blocker priorities: their merge requests are labelled `Blocker` and announced to the notification targets.
`ticketing.approvers`	empty (nobody)	Plan approvers: who may decide a plan from a ticket comment (account ids; GitHub logins, lower-cased; PagerDuty user ids).
`ticketing.type_mapping`	`Bug`→bug, `Story`→story, `Task`→story, `Small Enhancement Request`→story, `Epic`→epic, `Sub-task`→subtask	File only. Issue type to work class (`bug`, `investigation`, `story`, `epic`, `subtask`). Unmapped types are stories in tickets mode and investigations in incidents mode, where every incident's type is `Incident`. On GitHub Issues the type is the first label that names an entry here. Map a type such as `Support Question` to `investigation` to have its tickets reproduced and triaged rather than fixed.

Git host and integrations#

Settings → General (Git, Pull Requests, Commits, GitHub Integration), Settings → Reviewers and Settings → Worktree pool.

Key	Default	What it does
`git_branch_prefix`	`prepcook`	Branch Prefix of every branch an agent creates.
`workspace_dir`	unset (the default location)	Workspace Directory worktrees are created in.
`pr_auto_description_enabled`	`true`	Auto-generate PR description: after Shipped opens a pull request, the implementing agent writes its title and description.
`pr_auto_description_prompt`	unset (the shipped prompt)	The prompt for that follow-up.
`commit_reminder_enabled`	`true`	Commit reminder: an agent that ends a turn with uncommitted changes is told to commit.
`commit_reminder_prompt`	unset (the shipped prompt)	The reminder's text.
`github.pat`, `github.oauth_token`, `github.username`, `github.primary_email`, `github.default_pr_base`	unset	GitHub Integration. Pull requests are opened with the `gh` CLI, signed in on this machine.
`integrations.auto_assign_reviewers`	`true`	Auto-assign reviewers from blame on the lines a merge request changes.
`integrations.reviewer_map`	empty	Reviewer map: git author email to host login. Unmapped authors are named in a comment instead of assigned.
`integrations.reviewer_exclude_emails`	empty	Excluded author emails, on top of the agent's own.
`integrations.bot_logins`	empty	Ignored comment authors: merge-request comments from these logins are not fed to the agent.
`worktree_pool.enabled`	`false`	Enable worktree pool: reuse warm worktrees instead of creating one per workspace.
`worktree_pool.max_trees`	`8`	Max worktrees per repository.
`worktree_pool.root`	unset (the default location)	Pool root directory.

Notifications#

Settings → Integrations → Notifications. Where orchestrator events go: escalations, the daily digest, seat alerts, blocker merge requests and the rest (notifications.md lists every event). Any number of targets at once; each gets every event unless it names some.

Key	Default	What it does
`notifications.targets`	empty (none)	The targets, each `{ "kind": …, "events": […], …fields }`. `kind` is one of the providers below; the fields are that provider's.
`notifications.targets[].events`	unset (every event)	Event kinds this target receives; `["*"]` is every event too.

A config written with the older slack_webhook_url, slack_bot_token and slack_channel keys, or a board's slack override, is converted into Slack targets the first time it is read.

Evidence#

Settings → Integrations → Evidence. Where failures leave traces outside the reproduction: error trackers, log services, the app's log files. Each source is described to the planning agents, may give their sessions an MCP server, and is searched by evidence_search (evidence.md).

Key	Default	What it does
`evidence.sources`	empty (none)	The sources, each `{ "kind": …, "label": …, "areas": …, "notes": …, …fields }`. `kind` is one of the providers below; the fields are that provider's.
`orchestrator.project_defaults.<board>.evidence.enabled`	unset (on)	`false` turns every source off for the board, its own included.
`orchestrator.project_defaults.<board>.evidence.skip_global`	empty	Kinds of global source the board does not use.
`orchestrator.project_defaults.<board>.evidence.sources`	empty	Sources only that board uses, on top of the global ones it keeps.

A repository adds its own log files under [[profile.evidence]] in its .prepcook/scripts.toml (scripts.md). A config written with integrations.sentry_access_token or integrations.sentry_host is converted into a Sentry source the first time it is read.

Coding agents#

Generated from the agents' descriptors. executor_profile and every agents.stages entry name one of these as executor, with an optional variant; Settings → Agents probes each with its command and --version.

`executor`	Command	Signs in	MCP servers	Variants
`CLAUDE_CODE` (Claude Code)	`claude`	Run `claude` once and sign in, or set `ANTHROPIC_API_KEY` (billed per token instead of the subscription).	Per session, on its command line, on top of its own	`DEFAULT`, `SONNET` (economy)
`AMP` (Amp)	`npx -y @sourcegraph/amp@latest`	Run `amp login` once, or set `AMP_API_KEY`.	Only from its own config (Settings → MCP Servers)	`DEFAULT`
`GEMINI` (Gemini CLI)	`npx -y @google/gemini-cli@0.29.3`	Run `gemini` once and sign in with Google, or set `GEMINI_API_KEY`.	Only from its own config (Settings → MCP Servers)	`DEFAULT`
`CODEX` (Codex)	`npx -y @openai/codex@0.124.0`	Run `codex login` once, or set `CODEX_API_KEY`.	Per session, on its command line, on top of its own	`DEFAULT`
`OPENCODE` (OpenCode)	`npx -y opencode-ai@1.4.7`	Run `opencode auth login` once for each model provider it should use.	Only from its own config (Settings → MCP Servers)	`DEFAULT`
`CURSOR_AGENT` (Cursor Agent)	`cursor-agent`	Run `cursor-agent login` once, or set `CURSOR_API_KEY`.	Only from its own config (Settings → MCP Servers)	`DEFAULT`
`QWEN_CODE` (Qwen Code)	`npx -y @qwen-code/qwen-code@0.9.1`	Run `qwen` once and sign in, or set `OPENAI_API_KEY` for an OpenAI-compatible endpoint.	Only from its own config (Settings → MCP Servers)	`DEFAULT`
`COPILOT` (GitHub Copilot CLI)	`npx -y @github/copilot@0.0.403`	Run `copilot` once and use `/login`, or set `GH_TOKEN` to a token with Copilot access.	Only from its own config (Settings → MCP Servers)	`DEFAULT`
`DROID` (Droid)	`droid`	Run `droid` once and sign in, or set `FACTORY_API_KEY`.	Only from its own config (Settings → MCP Servers)	`DEFAULT`

Evidence sources#

Generated from the providers' descriptors. A secret field is read from the secrets store under the name shown, then from the config, then from the environment variable of that name; a board's own source reads its config value first. Every source also takes label, areas and notes (evidence.md), left out of the table.

`kind`	Field	Required	Secret name	What it is
`sentry` (Sentry)				The errors the app raised in production, grouped into issues: agent sessions get Sentry's MCP server, and evidence_search lists a project's issues seen in a window.
	`access_token`	yes	`SENTRY_ACCESS_TOKEN`	Access token. A user auth token (Settings → Account → API → Auth Tokens) with org:read, project:read and event:read.
	`host`	no		Host. The host name of a self-hosted Sentry, e.g. sentry.example.com. Blank is sentry.io.
	`org`	no		Organization slug. The organization in Sentry's URLs, e.g. acme. With the project, evidence_search can list issues; without them the agent has the MCP server only.
	`project`	no		Project slug. The project the app reports to, e.g. web.
	`environment`	no		Environment. Only issues seen in this environment, e.g. production. Blank is every environment.
`dataset` (DataSet)				Logs shipped to DataSet (Scalyr), searched with its query API.
	`read_token`	yes	`DATASET_READ_TOKEN`	Read Logs token. A "Read Logs" API token (API Keys in DataSet's settings).
	`server`	no		Server. Your account's region, e.g. https://app.eu.scalyr.com. Blank is https://app.scalyr.com.
	`filter`	no		Base filter. A DataSet filter every search is narrowed by, e.g. serverHost == "web-1" or $logfile contains "app".
`datadog` (Datadog)				Logs in Datadog, searched with the Logs Search API.
	`api_key`	yes	`DATADOG_API_KEY`	API key. An API key (Organization Settings → API Keys).
	`application_key`	yes	`DATADOG_APPLICATION_KEY`	Application key. An application key with the logs_read_data scope (Organization Settings → Application Keys).
	`site`	no		Site. Your Datadog site, e.g. datadoghq.eu or us5.datadoghq.com. Blank is datadoghq.com.
	`query`	no		Base query. Log search terms every search is narrowed by, e.g. service:web env:production.
`cloudwatch` (CloudWatch Logs)				A CloudWatch Logs group, searched through the aws CLI on this machine with the credentials it is configured with.
	`log_group`	yes		Log group. The log group's name, e.g. /ecs/pantry-web.
	`region`	no		Region. e.g. us-east-1. Blank uses the aws CLI's configured region.
	`profile`	no		Profile. The aws CLI profile to use. Blank uses its default credentials.
`log_files` (Log files)				Log files the app writes where it runs for the card, read on this machine; a repository can also name its own in [[profile.evidence]].
	`paths`	yes		Paths. Comma-separated files or globs, relative to the card's worktree (e.g. logs/app.log, logs/*.log) or absolute.

Notification providers#

`kind`	Field	Required	Secret name	What it is
`slack` (Slack)				Posts to a channel through an incoming webhook, a bot, or both; with a bot, escalation threads carry replies back to the agent and the digest keeps a channel canvas.
	`webhook_url`	no	`SLACK_WEBHOOK_URL`	Incoming webhook URL. A Slack incoming-webhook URL (https://hooks.slack.com/services/…). Needed unless a bot token and channel are set.
	`bot_token`	no	`SLACK_BOT_TOKEN`	Bot token. A bot token (xoxb-…) with chat:write, channels:history (or groups:history) and canvases:write; the bot must be in the channel. With a channel, escalations open a thread whose replies reach the blocked agent.
	`channel`	no		Channel ID. The channel the bot posts to, e.g. C0123456.
`webhook` (Webhook)				POSTs every event as signed JSON to a URL you run, for wiring Prepcook into anything else.
	`url`	yes		URL. Where events are POSTed. A 5xx or timeout is retried three times.
	`secret`	no	`WEBHOOK_SECRET`	Signing secret. Signs each body with HMAC-SHA256 in the X-PrepCook-Signature header. Unset sends unsigned requests.
`discord` (Discord)				Posts each event as an embed to a Discord channel through its webhook.
	`webhook_url`	yes	`DISCORD_WEBHOOK_URL`	Webhook URL. The channel's webhook (Channel settings → Integrations → Webhooks), https://discord.com/api/webhooks/….
`teams` (Microsoft Teams)				Posts each event as an Adaptive Card to a Teams channel through an incoming webhook.
	`webhook_url`	yes	`TEAMS_WEBHOOK_URL`	Webhook URL. The URL of a Teams workflow that posts webhook requests to a channel, or of a channel's Incoming Webhook connector.

Reproduction targets#

Generated from the providers' descriptors. Each field is a key of the app_runs section; a remote target has no global settings, only each repository's [app.remote]. A board picks its target with reproduction.target.

`kind`	Field	Required	What it is
`local` (This machine)			Builds and starts the app from [app] in the card's worktree and serves it on a port of this machine.
	`port_range`	yes	Port range. Ports handed to app runs, `<first>-<last>` inclusive; each run gets one as $PREPCOOK_PORT.
	`max_parallel`	yes	Apps at once. Local apps up at the same time. Each is a full app stack, so this is bounded by the machine's memory; a stand-up past it waits for the next scan.
`remote` (Remote deploy)			Runs [app.remote] from the repository's .prepcook/scripts.toml to deploy the branch to a preview environment, dev tenant or staging slot, and reproduces and verifies against the URL the deploy reports. Everything it runs is in the manifest; choose it per board.

Ticketing providers#

`kind`	Field	Required	Secret name	What it is
`jira` (Jira)				Jira Cloud: tickets come from a project, filters are JQL, and each stage moves the ticket to the status the workflow mapping names.
	`site`	yes		Site. Your Atlassian site's host name, e.g. example.atlassian.net.
	`email`	yes		Email. The email of the agent's Jira account, the one the API token belongs to.
	`api_token`	yes	`JIRA_API_TOKEN`	API token. An API token for that account (https://id.atlassian.com/manage-profile/security/api-tokens).
	`bot_identity`	no		Agent account id. The account id the agent's own comments are recognised by. Blank uses the account the token belongs to.
	`project_key`	no		Project key. The project tickets are imported from and filed into (default BUG).
	`import_filter`	no		Import filter. JQL the import dialog runs; {project_key} is substituted. Default: To Do tickets in open sprints assigned to you, by priority.
	`pickup_filter`	no		Pickup filter. JQL selecting new tickets to pick up; a created-recently window is added. Default: project = {project_key} AND priority in (P0, P1) AND issuetype = Bug.
	`assigned_filter`	no		Assigned pickup filter. JQL for tickets assigned to the agent, started whatever their priority, e.g. project = {project_key} AND assignee = currentUser(). Blank turns it off.
`github_issues` (GitHub Issues)				Issues in one repository, read and written through the gh CLI: it uses the account `gh auth login` signed in on this machine, so there is no token to enter. Stages are labels; done closes the issue.
	`repo`	yes		Repository. owner/name, or host/owner/name on GitHub Enterprise. Issue keys are the repository name and number, e.g. WIDGETS-42.
	`bot_identity`	no		Agent login. The login the agent's own comments are recognised by. Blank uses the account gh is signed in as.
	`import_filter`	no		Import filter. Terms the import dialog lists: state:open\|closed\|all, label:bug (repeatable; quote names with spaces), -label:wontfix, assignee:@me\|login\|none. Default: state:open assignee:@me.
	`pickup_filter`	no		Pickup filter. Which new issues are picked up, in the same terms; a created-recently window is added. Default: state:open label:bug.
	`assigned_filter`	no		Assigned pickup filter. Issues assigned to the agent, started whatever their labels, e.g. state:open assignee:@me. Blank turns it off.
`linear` (Linear) — not implemented				Linear is not implemented — contributions welcome. It can be named, and every call to it says it is not supported.
	`linear_api_key`	yes	`LINEAR_API_KEY`	API key. A Linear personal API key.
	`team_key`	yes		Team key. The team issues come from, e.g. ENG.
`pagerduty` (PagerDuty)				Incidents mode: open incidents become investigation cards, and the triage report goes back to the incident as a note. Prepcook never pages anyone and resolves an incident only when configured to.
	`pagerduty_api_token`	yes	`PAGERDUTY_API_TOKEN`	API key. A REST API key (Integrations → API Access Keys) that can read incidents and write notes.
	`user_id`	yes		User id. The PagerDuty user Prepcook writes as, e.g. PABC123: a dedicated user, not on any schedule, so nothing pages it.
	`service_ids`	no		Service ids. Comma-separated services whose incidents are picked up, e.g. PSVC123. Blank picks up every service the key can see.
	`pickup_filter`	no		Pickup filter. Which incidents are picked up: service:PSVC123, urgency:high\|low, status:triggered,acknowledged, assigned:@me, team:PTEAM12. Default: status:triggered,acknowledged.
	`import_filter`	no		Import filter. Incidents the import dialog lists, in the same terms. Default: status:triggered,acknowledged.

Agent MCP servers and skills#

Not settings, but where they end up. The agent sessions Prepcook launches get the prepcook MCP server (the prepcook-mcp binary beside the server, or in ~/.local/bin or /usr/local/bin) and the MCP server of every evidence source that has one (Sentry's, for each Sentry source with a token). Prepcook writes them to agent-mcp.json in the app data directory at startup and when the evidence sources change, and hands that file to each session: Claude Code through --mcp-config, which adds the servers to the user's own for that session only, and Codex as a thread config override (prepcook only). The other agents have no per-session mechanism and get the servers only from their own config.

The skills in assets/agent-skills/ reach Claude Code sessions the same way: Prepcook writes them under agent-skills/.claude/skills/ in the app data directory, refreshing them as each session starts, and passes that directory with --add-dir, which loads its skills for that session only. Nothing is written into the worktree.

Prepcook never writes to an agent's own config (Claude Code's user config and ~/.claude/skills, ~/.codex/config.toml and the like) on its own, so sessions outside Prepcook load only what their user installed. Settings → MCP Servers edits that config when you save there, and the toolkit's setup.sh registers prepcook in Claude Code's user config and links the prepcook-* skills into ~/.claude/skills when you run it (toolkit/README.md); nothing else does.

App runs#

Settings → Reproduction. Where bug cards' apps are stood up: the local target on this machine, or the remote target, which deploys with each repository's [app.remote] (scripts.md). The reproduction targets are listed under Reproduction targets.

Key	Default	What it does
`app_runs.port_range`	`4200-4299`	Port range: ports handed to local app runs, inclusive.
`app_runs.max_parallel`	`2`	Apps at once: local apps up at once. A stand-up past this waits for the next scan. Remote apps are capped by `[app.remote] max_parallel` instead.
`app_runs.default_target`	`local`	Default target: `local` or `remote`, for every board that does not choose.

Board#

Not part of config.json: the board is configured from the environment, and the board stack reads its own .env (<app data dir>/board/.env, written by prepcook up). There is no sign-in: the server signs every request to the board with the board's secret.

Variable	Default	What it does
`PREPCOOK_SHARED_API_BASE`	`http://127.0.0.1:4110` under `prepcook up`, else unset	The board's URL. Unset, the board features are off.
`PREPCOOK_BOARD_SECRET` (secret)	the board `.env`'s `PREPCOOK_JWT_SECRET`	The board's JWT secret, which the server signs its owner tokens with. `prepcook up` reads it from the `.env` of the board it starts. A server started by hand reads the environment variable, then `PREPCOOK_BOARD_SECRET` in the secrets store, then (for the board on `127.0.0.1:4110`) the board `.env`. Without one the server still starts, and the UI says there is no board secret.
`PREPCOOK_JWT_SECRET` (board `.env`)	generated	Standard base64 of at least 32 bytes; signs agent sessions' tokens and verifies owner tokens.
`DB_PASSWORD`, `ELECTRIC_ROLE_PASSWORD` (board `.env`)	generated	The board's database passwords.

The board reads no sign-in or OAuth settings: SELF_HOST_LOCAL_AUTH_EMAIL, SELF_HOST_LOCAL_AUTH_PASSWORD and GITHUB_/GOOGLE_OAUTH_CLIENT_ID and _SECRET lines in a board .env are ignored.

Approvals#

Key	Default	What it does
`approvals.in_app_gate`	`lavish`	Settings → Orchestrator → Plan approvals. `lavish` puts Approve and Request changes buttons in the plan document; `none` leaves them out and the decision comes from the card, the ticket or the API (approvals.md).
`ticketing.approvers`	empty	See Ticketing.
`PREPCOOK_API_TOKEN` (secret)	unset (bearer access off)	The bearer token the approvals and card APIs accept from scripts and other services (api.md). Filing a card needs it.

Secrets#

Settings → Secrets, or prepcook secret set|list|unset. Not part of config.json: values live in ~/.config/prepcook/secrets.env (mode 0600). PREPCOOK_SECRETS_FILE points Prepcook at another file, and an environment variable PREPCOOK_SECRET_<NAME> overrides an entry. A repository's [secrets] requires names the ones its scripts need (scripts.md).

Playbooks#

Key	Default	What it does
`playbooks`	the shipped texts	Settings → Playbooks, scope Global: the prompt each stage's agent starts from, keyed `<work_class>:<stage>` (`investigation:planning` among them) plus `pattern:planning`, `reviewing`, `comment_reply` and `rca_analysis` (playbooks.md).
`playbook_keys`	`1`	Kept by Prepcook. Which key names `playbooks` uses. A config without it was saved before `investigation:planning` (the pattern review's text) became `pattern:planning` and `triage` became `comment_reply`; both are renamed, globally and in every board's overrides, the first time it is read.

Per-board overrides#

Under orchestrator.project_defaults["<board id>"], shown per board in Settings → Orchestrator → Automated projects → Board overrides. Unset or empty inherits the global value.

Key	Default	What it does
`repo_ids`	empty	Repositories checked out for this board's workspaces. Required.
`label`	unset	Board label: tagged on its RCAs as `board:<label>`.
`executor_profile`	unset (inherit)	Default agent: the profile this board's stages start from.
`agents.stages.<stage>`	unset (inherit)	Planning, Executing, Reviewing, Comment replies, Pattern reviews: this board's profile for that stage, over the global one (Agents).
`autonomy`	unset (inherit)	Autonomy for this board.
`autonomy_review_iterations`	unset (inherit)	Review-fix rounds for this board.
`pattern_threshold`	unset (inherit)	Pattern-review threshold for this board (`investigation_threshold` in older configs).
`deployed_retention`	`inherit`	`off`, or `{ "days": n }`: days in an older board's Close before Clean up.
`cleanup_retention`	`inherit`	`off`, or `{ "days": n }`: days in Clean up before deletion.
`ticketing.watcher_enabled`	unset (on only for `ticketing.project_id`)	Ticket pickup for this board. Older configs call the override `tracker` or `jira`; both are read.
`ticketing.jql_filter`	unset (inherit)	Pickup filter for this board, in the provider's syntax.
`ticketing.assigned_jql`	unset (inherit)	Assigned pickup filter for this board; blank inherits.
`ticketing.project_key`	unset (inherit)	Tracker project key, when this board's tickets live elsewhere.
`notifications.enabled`	unset (on)	Notifications: `false` silences every target for this board.
`notifications.skip_global`	empty	Kinds of global target (`slack`, `webhook`, …) this board does not send to.
`notifications.targets`	empty	Targets only this board sends to, on top of the global ones it keeps; same shape as `notifications.targets`.
`merge_requests.auto_assign_reviewers`	unset (inherit)	Assign reviewers from blame.
`merge_requests.reviewer_map`	empty	Reviewer map additions, merged over the global map.
`merge_requests.reviewer_exclude_emails`	empty	Exclude authors, added to the global list.
`merge_requests.bot_logins`	empty	Ignore MR comments from, added to the global list.
`deploy_watch`	unset (off)	Staging deploy job and branch: records when each merged change reaches staging. Both are needed.
`reproduction.target`	unset (inherit `app_runs.default_target`)	Settings → Reproduction → Boards: `local` or `remote`. A board set to `remote` whose repository has no `[app.remote]` stops its stand-ups with `target-unconfigured`.
`playbooks`	empty	Settings → Playbooks, scope this board: texts for this board only.

Everything else#

Settings → General, and state Prepcook keeps for itself.

Key	Default	What it does
`theme`	`SYSTEM`	Theme.
`language`	`BROWSER`	Language.
`editor.editor_type`	`VS_CODE`	Editor Type that "open in editor" uses; `custom_command`, `remote_ssh_host` and `remote_ssh_user` are unset.
`notifications.sound_enabled`, `.push_enabled`	`true`, `true`	Sound and Push Notifications.
`notifications.sound_file`	`COW_MOOING`	Sound.
`send_message_shortcut`	`ModifierEnter`	Send message with.
`analytics_enabled`	`true`	Enable Telemetry.
`disclaimer_acknowledged`, `onboarding_acknowledged`, `remote_onboarding_acknowledged`	`false`	Whether the first-run screens were seen.
`showcases`, `last_app_version`, `show_release_notes`	empty, unset, `false`	What the app has already shown you.
`config_version`	`v10`	The shape of the file. An older file is upgraded when read.