Skip to main content

Accessing settings

To configure droid settings:
  1. Run droid
  2. Enter /settings
  3. Adjust your preferences interactively
Changes take effect immediately and are saved to your settings file.

Where settings live

If the file doesn’t exist, it’s created with defaults the first time you run droid.

Local overrides

You can create a settings.local.json alongside settings.json in any .factory/ folder:
  • ~/.factory/settings.local.json (user-level)
  • <project>/.factory/settings.local.json (project-level)
Local overrides merge on top of the corresponding settings.json at the same level and follow the same hierarchy precedence. Add settings.local.json to .gitignore if you want to keep machine-specific preferences out of version control.

Legacy Droid YAML configuration

.droid.yaml was an older project configuration surface. Use the current .factory/ files instead:
  • Use settings.json and settings.local.json for Droid preferences and local overrides.
  • Use AGENTS.md for repository instructions, conventions, and validation commands.
  • Use MCP servers, hooks, and skills for integrations, automation, and reusable workflows.

Available settings

Model

Set sessionDefaultSettings.model to a model ID from Available Models. For custom models, see Bring Your Own Key (BYOK).
For backward compatibility, model, reasoningEffort, autonomyMode, specModeModel, and specModeReasoningEffort are also accepted as top-level keys; droid migrates them into sessionDefaultSettings on load. New configurations should nest them under sessionDefaultSettings.

Reasoning effort

sessionDefaultSettings.reasoningEffort controls how much structured thinking the model performs before replying. The model picker and the Available Models Reasoning column show these levels as display labels; use the matching value below in settings.json: Higher effort increases latency and cost. Which levels are available — and which is the default — depend on the model, so check the Reasoning column in Available Models. Display labels can vary slightly by surface (for example, max may appear as Max or Maximum).

Autonomy level

Use sessionDefaultSettings.interactionMode to choose whether new sessions start in Auto or Spec Mode, and sessionDefaultSettings.autonomyLevel to set the default Autonomy Level. off keeps manual approvals; low, medium, and high pre-authorize work at or below that risk level. sessionDefaultSettings.autonomyMode is deprecated and retained for older configurations.

Diff mode

Control how droid displays code changes:
  • github – Side-by-side, higher fidelity render (recommended).
  • unified – Traditional single-column diff format.

Cloud session sync

When this switch is on, every CLI session is mirrored to Factory web so you can revisit conversations in the browser:
  • true – Sync sessions to the web app.
  • false – Keep sessions local only.

Sound notifications

Configure audio feedback for droid events: Completion sound (completionSound) - plays when a response finishes:
  • fx-ok01 – Built-in completion sound (default) - soft success bloop
  • fx-ack01 – Alternative built-in sound effect - tactile ripple feedback
  • bell – Use the system terminal bell
  • off – No sound notifications
  • Custom path – Provide a file path to your own sound file (e.g., "/path/to/sound.wav")
Awaiting input sound (awaitingInputSound) - plays when droid is waiting for user input. Same options as completion sound, defaults to fx-ack01. Sound focus mode (soundFocusMode) - controls when sounds play:
  • always – Play sounds regardless of window focus (default)
  • focused – Only play sounds when the terminal is focused
  • unfocused – Only play sounds when the terminal is not focused
Access sound settings via /settings or Shift+TabSettings in the TUI.

Hooks

The hooksDisabled setting provides a global toggle to disable all hooks execution without removing your hook configurations:
  • false – Hooks are enabled and will execute normally (default)
  • true – All hooks are disabled globally
You can also toggle this from the /hooks menu or /settings.

IDE auto-connect

The ideAutoConnect setting controls whether droid automatically connects to your IDE when running from external terminals (outside the IDE’s built-in terminal):
  • false – Only auto-connect when running inside IDE terminal (default)
  • true – Auto-connect to IDE from any terminal

Command allowlist & denylist

Use these settings to control which commands droid can execute automatically and which it must never run:
  • commandAllowlist – Commands in this array are treated as safe and run without additional confirmation, regardless of autonomy prompts. Include only low-risk utilities you rely on frequently (for example ls, pwd, dir).
  • commandDenylist – Commands in this array always require confirmation and are typically blocked because they are destructive or unsafe (for example recursive rm, mkfs, or privileged system operations).
Commands that appear in both lists default to the denylist behavior. Any command that is in neither list falls back to the autonomy level you selected for the session.

Example allow/deny configuration

Review and update these arrays periodically to match your workflow and security posture, especially when sharing configurations across teams.

Session defaults

Defaults applied when a new session starts. See also sessionDefaultSettings.interactionMode and sessionDefaultSettings.autonomyLevel in the table above.

Display and UI

Tune how droid renders content in the terminal.

Additional sound and notification settings

Extends the Sound notifications section with toggles for the bell, per-event focus modes, and subagent activity.

Mission settings

Configure Missions — multi-agent orchestration runs.

Context and compaction

Controls when and how droid compacts the conversation to stay within the model’s context window.

Spec mode settings

Controls the persistent spec store created by Spec Mode.

Infrastructure

System-level settings for status line, worktrees, and request timeouts.

Enterprise and org-level settings

Enterprise / Org-level. The settings below are typically managed by an organization administrator and pushed to members through the Factory web app or a managed settings.json. Individual users generally do not set these directly.

Example configuration


Need more?