ファイルの場所
Windows では、ユーザー設定のパスは
~\.config\devin\config.json ではなく、%APPDATA%\devin\config.json です (例: C:\Users\<you>\AppData\Roaming\devin\config.json) 。完全な設定リファレンス
- ユーザー設定
- プロジェクト設定
オプションリファレンス
ユーザーのみ と記載されたオプションは、ユーザー設定 (
~/.config/devin/config.json、Windows では %APPDATA%\devin\config.json) でのみ設定できます。プロジェクト設定で利用できるのは、permissions、mcpServers、read_config_from、hooks のみです。agent (ユーザーのみ)
theme_mode (ユーザーのみ)
権限
mcpServers
show_path (ユーザーのみ)
入力欄の枠線に現在の作業ディレクトリのパスを表示します。有効にすると、入力ボックス上部の枠線に、見やすい形式の CWD (例:~/projects/my-app) が表示されます。
unicode_mode (ユーザーのみ)
ターミナルUIで Unicode 記号を利用するか、ASCII で安全に表示できる代替文字を利用するかを制御します。端末やフォントで Unicode グリフが正しく表示されない場合 (例: ⏺ 記号が四角で表示される場合) は、"ascii" に設定してください。
show_hints (ユーザーのみ)
会話の合間に、ときどきヒントを表示します (例: 「ご存じですか?/model を利用すると、利用可能なモデルを切り替えられます」) 。CLIの機能を見つけるのに便利です。使い方に慣れたら、表示しないように false に設定してください。
include_gitignored_files (ユーザーのみ)
@ タブ補完の結果に、.gitignore で無視されるファイルを含めます。有効にすると、.gitignore パターンに一致するファイルが @ メンション補完に表示されます。参照したいドキュメントやその他のファイルを、.gitignore で無視されるディレクトリに保存している場合に便利です。
respect_gitignore (ユーザーのみ)
ツール経由でファイルを読み書きする際に、エージェントが.gitignore を尊重するかどうかを制御します。有効にすると、gitignore されたパスにアクセスするツール呼び出しはブロックされます。これは include_gitignored_files とは別の設定で、後者は @ タブ補完にのみ影響します。
attribution (ユーザーのみ)
エージェントが作成するコミットとプルリクエストに、Devin の帰属情報を追加するかどうかを制御します。有効にすると、コミット本文と PR 本文にGenerated with [Devin] 行と Co-Authored-By: Devin トレーラーが含まれます。どちらも追加しない場合は、false に設定します。
auto_update (ユーザーのみ)
macOS と Linux でバックグラウンド自動更新を制御します。有効にすると、Devin CLI の実行中に新しいリリースがダウンロードされて有効化されるため、次回devin を起動した際に自動的に最新バージョンが利用されます。現在実行中のセッションには影響ありません。current シンボリックリンクの切り替えが反映されるのは、次回の起動時のみです。
この更新は、中断が発生しても安全なように設計されています。ファイルシステム上の各ステップは一時パスで準備してから、アトミックなリネームで切り替えます。また、同時に実行される更新処理はファイルロックによって直列化されます。更新の途中で終了しても、インストールが壊れた状態になることはありません。再起動後は以前のバージョンがそのまま利用されるだけです。
自身で管理するインストールにのみ適用されます (macOS/Linux での curl | bash) 。別の製品に同梱されたインストール (例: Windsurf) ではこの設定は無視され、親アプリケーション経由で更新されます。
notify
read_config_from
特定のインポートを無効にするには、対応する値を
false に設定します。null は true として扱われます。
proxy (ユーザーのみ)
CLI自身の外向きHTTP/HTTPSトラフィック (APIコール、アップデート、MCPサーバーなど) をどのようにルーティングするかを設定します。これはsandboxの子プロセスのネットワーク通信には影響しません (下記のsandbox を参照) 。
mode フィールドでプロキシ戦略を選択します:
例 — 社内プロキシ:
sandbox (ユーザーのみ)
sandbox のドメイン単位のネットワークフィルタリングを設定します。--sandbox がアクティブで、ドメインフィルタリングが設定されている場合、管理対象のネットワークプロキシがループバック上で起動し、sandbox はすべての子プロセスのトラフィックをそのプロキシ経由に制限します。
sandbox の仕組みの全体像 — Enterprise による強制適用や、Enterprise 設定とユーザー設定の相互作用を含む — については、sandbox ドキュメント を参照してください。
--sandbox フラグは、アクティブな Read / Write の permission scope を OS レベルで強制適用します。書き込み可能なルートは、許可された Write(...) scope とワークスペースのディレクトリから決まり、読み取り可能なルートは Read(...) scope から決まります (プラットフォームのデフォルトは常に読み取り可能です) 。セッション中に新たに付与された scope は、後続のコマンドに対して sandbox を動的に拡張します。
--sandbox が指定されていても sandbox の解決に失敗した場合 (e.g.、現在のプラットフォームでsandbox化ツールを利用できない場合) 、CLI はsandboxなしで実行するのではなく起動を拒否します。このフェイルクローズの動作により、--sandbox のセキュリティ上の意図が気付かないうちに回避されることはありません。
ドメインパターンの構文:
例:
ドメインフィルタリングは、sandbox がアクティブな場合 (
--sandbox) に適用されます。--sandbox を指定しない場合、sandbox のセクションは無視されます。Enterprise Team では、管理者は チーム設定 からドメインリストを上書きできます。Enterprise の許可リストが基準となるため、ローカルの
allowed_domains は置き換えられます。一方、Enterprise の拒否リストは追加式で、ローカルの denied_domains にマージされます。
