harness-settings
Configure provider-specific settings (permissions, model, features) for Claude Code, OpenAI Codex CLI, and GitHub Copilot using the harness settings entity.
Best use case
harness-settings is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Configure provider-specific settings (permissions, model, features) for Claude Code, OpenAI Codex CLI, and GitHub Copilot using the harness settings entity.
Teams using harness-settings should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/harness-settings/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How harness-settings Compares
| Feature / Agent | harness-settings | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Configure provider-specific settings (permissions, model, features) for Claude Code, OpenAI Codex CLI, and GitHub Copilot using the harness settings entity.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# /harness-settings
Manage provider-specific configuration — permissions, model selection, sandboxing, environment variables, and feature flags — through the harness `settings` entity.
## What is the settings entity?
The `settings` entity lets you commit provider-specific configuration into `.harness/src/settings/` and have harness write it to the correct provider config file on `apply`. Unlike entities such as `prompt`, `skill`, or `mcp`, settings are inherently per-provider: each file targets exactly one provider and is written to that provider's native config location.
**Source files:**
| Provider | Source | Output |
|---|---|---|
| `claude` | `.harness/src/settings/claude.json` | `.claude/settings.json` |
| `codex` | `.harness/src/settings/codex.json` | `.codex/config.toml` (merged with MCP/subagent/hook state) |
| `copilot` | `.harness/src/settings/copilot.json` | `.github/copilot-settings.json` |
Per-provider override sidecars (`.overrides.<provider>.yaml`) are not applicable to settings entities — the file is already provider-specific.
**Important:** The `hooks` key in `.claude/settings.json` is managed by the `hook` entity. Do not set `hooks` inside `claude.json` — it will be merged in from your hook sources at apply time. Similarly, for Codex, `mcp_servers`, `agents`, and `notify` entries are merged in from their respective entity types; set only the keys your settings entity owns.
---
## CLI commands
```bash
# Scaffold a settings source file
npx harness add settings claude
npx harness add settings codex
npx harness add settings copilot
# Preview what will be written
npx harness plan
# Write settings to provider config files
npx harness apply
# Remove a settings entity (keeps source by default)
npx harness remove settings claude
npx harness remove settings claude --no-delete-source
```
---
## Claude Code (`claude.json`)
Written to `.claude/settings.json`. This is the project-scoped settings file committed to git and shared with your team.
### Common fields
| Key | Type | Description |
|---|---|---|
| `permissions` | object | Tool allow/deny/ask rules — see below |
| `model` | string | Override default model, e.g. `"claude-sonnet-4-6"` |
| `apiKeyHelper` | string | Shell script path to generate an auth token (`X-Api-Key` / `Authorization: Bearer`) |
| `env` | object | Environment variables injected into every session |
| `cleanupPeriodDays` | number | Delete sessions inactive longer than N days (default: 30; `0` disables persistence) |
| `autoUpdatesChannel` | string | `"stable"` or `"latest"` (default) |
| `includeGitInstructions` | boolean | Include built-in commit/PR workflow instructions in system prompt (default: `true`) |
| `companyAnnouncements` | string[] | Messages shown to users at startup |
| `attribution` | object | Customize git commit/PR attribution strings |
| `language` | string | Claude's preferred response language, e.g. `"japanese"` |
| `effortLevel` | string | Persist effort level across sessions: `"low"`, `"medium"`, or `"high"` |
| `alwaysThinkingEnabled` | boolean | Enable extended thinking by default |
| `outputStyle` | string | Configure an output style preset |
| `agent` | string | Run the main thread as a named subagent |
| `enableAllProjectMcpServers` | boolean | Auto-approve all MCP servers in `.mcp.json` |
| `enabledMcpjsonServers` | string[] | Approve specific MCP servers from `.mcp.json` |
| `disabledMcpjsonServers` | string[] | Reject specific MCP servers from `.mcp.json` |
| `sandbox` | object | Advanced sandboxing — see below |
| `worktree` | object | Worktree symlink and sparse-checkout settings |
| `statusLine` | object | Custom status line command |
| `plansDirectory` | string | Override where plan files are stored |
### Permissions
The `permissions` object lives inside the `settings.json` root. Rules are evaluated: deny first, then ask, then allow. First match wins.
```json
{
"permissions": {
"defaultMode": "acceptEdits",
"allow": ["Bash(npm run *)", "Bash(git *)", "Read(~/.zshrc)"],
"ask": ["Bash(git push *)"],
"deny": ["Bash(curl *)", "Read(./.env)", "Read(./secrets/**)"],
"additionalDirectories": ["../docs/"]
}
}
```
**`defaultMode` options:**
| Value | Behavior |
|---|---|
| `"default"` | Normal interactive permission prompts |
| `"acceptEdits"` | Auto-accept file edits; prompt for other tools |
| `"bypassPermissions"` | Skip all permission prompts (non-interactive CI use) |
**Rule syntax:** `Tool` or `Tool(specifier)`. Examples:
- `"Bash"` — all Bash commands
- `"Bash(npm run *)"` — commands starting with `npm run`
- `"Read(./.env)"` — reading the `.env` file
- `"WebFetch(domain:example.com)"` — fetches to example.com
- `"mcp__*"` — all MCP tool calls
**Managed-only permission keys** (for enterprise `managed-settings.json`):
- `disableBypassPermissionsMode: "disable"` — prevent `--dangerously-skip-permissions`
- `allowManagedPermissionRulesOnly: true` — block user/project allow/deny rules
- `allowManagedMcpServersOnly: true` — enforce MCP allowlist from managed settings
### Sandbox settings
```json
{
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": true,
"excludedCommands": ["docker", "git"],
"filesystem": {
"allowWrite": ["/tmp/build", "~/.kube"],
"denyRead": ["~/.aws/credentials"]
},
"network": {
"allowedDomains": ["github.com", "*.npmjs.org"]
}
}
}
```
### Copy-paste example
This is a typical project-level `claude.json` for a team repo:
```json
{
"$schema": "https://json.schemastore.org/claude-code-settings.json",
"model": "claude-sonnet-4-6",
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
},
"permissions": {
"defaultMode": "acceptEdits",
"allow": [
"Bash(npm run *)",
"Bash(pnpm *)",
"Bash(git diff *)",
"Bash(git log *)",
"Bash(git status)",
"Read",
"Edit",
"Write",
"mcp__*"
],
"ask": [
"Bash(git push *)",
"Bash(git commit *)"
],
"deny": [
"Bash(curl *)",
"Bash(wget *)",
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)"
]
},
"includeGitInstructions": true,
"autoUpdatesChannel": "stable",
"companyAnnouncements": [
"Run pnpm check:write before committing."
]
}
```
---
## OpenAI Codex CLI (`codex.json`)
Written to `.codex/config.toml` and merged with MCP server entries, agent definitions, and hook `notify` commands from their respective entities. Only set the keys your settings entity owns — do not duplicate `mcp_servers`, `agents.<name>`, or `notify`.
### Common fields
| Key | Type | Description |
|---|---|---|
| `model` | string | Model to use, e.g. `"gpt-5-codex"` |
| `model_provider` | string | Provider ID (default: `"openai"`); use `[model_providers.<id>]` for custom providers |
| `model_reasoning_effort` | string | `"minimal"`, `"low"`, `"medium"`, `"high"`, or `"xhigh"` |
| `model_reasoning_summary` | string | `"auto"`, `"concise"`, `"detailed"`, or `"none"` |
| `approval_policy` | string/object | `"untrusted"`, `"on-request"`, `"never"`, or granular object |
| `sandbox_mode` | string | `"read-only"` (default), `"workspace-write"`, `"danger-full-access"` |
| `web_search` | string | `"disabled"`, `"cached"` (default), or `"live"` |
| `service_tier` | string | `"flex"` or `"fast"` |
| `developer_instructions` | string | Injected session guidance |
| `history.persistence` | string | `"save-all"` or `"none"` |
| `features.shell_tool` | boolean | Enable/disable default command execution tool |
| `features.multi_agent` | boolean | Enable agent collaboration tools |
| `features.web_search` | boolean | Toggle web search |
| `features.fast_mode` | boolean | Enable fast mode feature flag |
| `agents.max_threads` | number | Concurrent thread limit (default: 6) |
| `agents.max_depth` | number | Max nesting depth for spawned threads |
### Copy-paste example
```json
{
"model": "gpt-5-codex",
"model_reasoning_effort": "medium",
"approval_policy": "on-request",
"sandbox_mode": "workspace-write",
"web_search": "cached",
"features": {
"shell_tool": true,
"multi_agent": true
},
"agents": {
"max_threads": 4
}
}
```
---
## GitHub Copilot (`copilot.json`)
GitHub Copilot's primary customization surface is `.github/copilot-instructions.md` (managed by the `prompt` entity) and `.vscode/mcp.json` (managed by the `mcp` entity). The `copilot.json` settings entity handles remaining provider-level configuration written to `.github/copilot-settings.json`.
Copilot's custom instructions, agent skills, and MCP servers are all managed by their respective harness entities — not by the settings entity.
---
## Entity interactions
| Concern | Entity to use |
|---|---|
| Claude permissions, model, env vars | `settings claude` |
| Claude lifecycle hooks | `hook` |
| Claude MCP servers | `mcp` |
| Claude subagents | `subagent` |
| Codex model, approval policy, sandbox | `settings codex` |
| Codex MCP servers | `mcp` |
| Codex hook notifications | `hook` |
| Copilot system instructions | `prompt` |
| Copilot MCP servers | `mcp` |
---
## Typical workflow
```bash
npx harness add settings claude
# Edit .harness/src/settings/claude.json
npx harness plan # verify what will be written
npx harness apply # write .claude/settings.json
```
To manage settings alongside other entities in a single apply:
```bash
npx harness add settings claude
npx harness add mcp my-server
npx harness add hook guard
# Edit source files
npx harness apply # writes all provider artifacts at once
```
---
## Official documentation
- Claude Code settings reference: https://code.claude.com/docs/en/settings
- Claude Code permissions: https://code.claude.com/docs/en/permissions
- Claude Code sandboxing: https://code.claude.com/docs/en/sandboxing
- OpenAI Codex CLI config reference: https://developers.openai.com/codex/config-reference
- OpenAI Codex CLI sample config: https://developers.openai.com/codex/config-sample
- GitHub Copilot custom instructions: https://docs.github.com/en/copilot/customizing-copilot/adding-custom-instructions-for-github-copilot
- GitHub Copilot VS Code settings: https://code.visualstudio.com/docs/copilot/reference/copilot-settingsRelated Skills
harness-subagent
Create and manage subagent entities in the agent-harness workspace. Invoke this skill when a user wants to define, scaffold, apply, or remove a subagent across Claude Code, OpenAI Codex, or GitHub Copilot.
harness-skill
Create and manage skill entities in the agent-harness workspace. Use when the user wants to add a new skill, understand how skills work across providers, or generate provider skill artifacts from a canonical source.
harness-prompt
Create and manage the system prompt entity in agent-harness, generating CLAUDE.md, AGENTS.md, and copilot-instructions.md from a single canonical source.
harness-mcp
Create and manage MCP server config entities in the agent-harness workspace.
harness-hook
Create and manage lifecycle hook entities in the agent-harness workspace. Covers canonical event authoring, provider projection (Claude Code, GitHub Copilot, OpenAI Codex CLI, Cursor), mode behavior, handler types, the full event/provider support matrix, copy-paste recipes, and common diagnostics.
npm-workflow-release
Release agent-harness packages to npm and verify publication. Use when the user asks to cut a release, push a missing release tag, or troubleshoot why a version was not published.
harness-writing
Writing effective fuzzing harnesses for security testing.
configuring-windows-defender-advanced-settings
Configures Microsoft Defender for Endpoint (MDE) advanced protection settings including attack surface reduction rules, controlled folder access, network protection, and exploit protection. Use when hardening Windows endpoints beyond default Defender settings, deploying enterprise-grade endpoint protection, or meeting compliance requirements for advanced malware defense. Activates for requests involving Windows Defender configuration, ASR rules, MDE tuning, or Microsoft endpoint security.
scenario-verification-harness
Applies the Robota scenario verification loop by checking scope, preserving canonical ownership, re-recording only when necessary, and stopping on strict-policy failures. Use when scenario files, example flows, or execution-path behavior changes.
pre-refactor-test-harness
Before modularizing or refactoring a package, analyze the code for extraction points, write characterization tests for current behavior, then modularize under test protection. Use when a package has monolithic files that need to be broken into testable modules.
harness-governance
Governs the Robota harness by checking rule-skill-owner consistency, finding undefined terminology, spotting examples that violate rules, and preferring mechanical checks over duplicated prose. Use when editing AGENTS, skills, or repository guidance.
plugin-settings
This skill should be used when the user asks about "plugin settings", "store plugin configuration", "user-configurable plugin", ".local.md files", "plugin state files", "read YAML frontmatter", "per-project plugin settings", or wants to make plugin behavior configurable. Documents the .claude/plugin-name.local.md pattern for storing plugin-specific configuration with YAML frontmatter and markdown content.