When a task says "Repo config not trusted"

A repository can commit files that make a coding agent run a command. Examples are hooks, helper programs and plugins. A device does not trust those files by default. This page explains the refusal, and how you fix it.

What triggers the refusal

Before a session starts, the device scans the repository’s working folder, up to the repo root. It refuses the session when it finds config that runs commands or loads code.

For Claude Code, these files count:

• .claude/settings.json and .claude/settings.local.json, when they set hooks, statusLine, apiKeyHelper, env, enabledPlugins or extraKnownMarketplaces. Other helper-command keys count too, such as the AWS and GCP sign-in helpers.
• Agent files in .claude/agents/, when the frontmatter sets hooks or mcpServers.
• A skill in .claude/skills/, when its SKILL.md frontmatter sets hooks or mcpServers. A skill that CodeHerder delivers for the session does not count.

Other keys, such as permissions and model, do not trigger it. The instructions files CLAUDE.md and AGENTS.md do not trigger it either.

The same rule covers some files for two other harnesses:

• Cursor: .cursor/hooks.json and .cursor/mcp.json.
• OpenCode: opencode.json or .opencode/opencode.json (also the .jsonc forms) that set plugin, mcp, formatter or lsp, and non-empty plugin or tool folders under .opencode/ (plugin/, plugins/, tool/ or tools/).

A committed .mcp.json does not refuse the session. By default, Claude starts in a mode that ignores it, so its servers never run. A marketplace approval alone keeps it off. Trust the repo or the whole device to load its servers.

What you see

CodeHerder tries another device that can run the task. It then skips the refusing device for that task for 24 hours.

When every capable device refuses, the task shows a Start refused badge with the reason Repo config not trusted. ch task show <taskId> shows the same reason in its start refusal row. The refused session records which files and keys the device found. The message is short, so a long list can end with “shortened”.

Fix it, narrowest first

1. Remove the config from the repo. This is the safest fix. A repo without these files starts normally.
2. Trust a plugin marketplace. Set CH_TRUST_HARNESS_MARKETPLACES on the device to the marketplaces you approve. Use github:owner/repo or a git remote. This covers only the enabledPlugins and extraKnownMarketplaces keys. Hooks, helper commands and env still refuse. A plugin’s own MCP servers stay off.
3. Trust one repo. Set CH_TRUST_HARNESS_REPOS on the device to the repo, for example github.com/acme/app. The device then accepts everything that repo commits. Claude also runs the repo’s .mcp.json servers and the MCP servers of its plugins.
4. Trust every repo on the device. Set CH_TRUST_REPO_HARNESS_CONFIG to true. This is the broadest choice. It overrides the two lists. Every repo’s hooks, plugins and MCP servers then run.

All three settings weaken isolation. A trusted repo runs its commands as the user who runs the device server, with no prompt. Trust only repos whose contributors you trust. See Who can run code on your device and Isolating agent runs on a device.

How the lists match

• Write each entry as a comma-separated item. A list holds at most 64 entries.
• A repo entry is a git remote or a host/owner/repo path. The match is exact and ignores case, the scheme, a user name, a port and a trailing .git.
• A wildcard, a bare name such as app, or an entry with no owner or repo is rejected when you save it. A bad value in the device’s own environment stops the device server at start.
• The device matches a marketplace by its source repository, never by its name. A repo that defines a marketplace with the same name but a different source stays refused.
• A plugin must name a marketplace that the repo’s own settings define.
• The device checks only the repo that holds the session’s working folder. Trusting one repo does not trust a second repo that the same task attached.
• A session that starts in a parent folder has no repo to match. Only the marketplace list or the whole-device setting admits it. See Start from a parent folder of repos.

Apply and undo a change

Set the value in the device’s Settings section in the web app, or as an environment variable on the device. See Changing a device’s settings.

A new value takes effect after an operator restarts the device. The device never restarts itself. After a restart that applies a changed value, the 24-hour skip ends for that device and the task tries it again. To end the skip without a change, run:

ch device clear-provision-breaker <device>

To undo trust, remove the entry, or clear the setting, then restart the device. The next session is scanned again. A session that already runs keeps what it loaded.

Related guides

• Changing a device’s settings — where to set these values
• Who can run code on your device — what a trusted repo can do
• Isolating agent runs on a device — limit what an agent reaches
• When a task is not moving — find the cause of a stuck task
• Skills — the skills that CodeHerder delivers to a session