Claude Code 企业级 Settings 配置实战从 lax / strict 基线到 Bash 沙箱与 MDM 托管下发【免费下载链接】claude-codeClaude Code is an agentic coding tool that lives in your terminal, understands your codebase, and helps you code faster by executing routine tasks, explaining complex code, and handling git workflows - all through natural language commands.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-codeClaude Code 是一款运行在终端中的 Agent 式编码工具能够理解代码库并通过自然语言执行日常任务、解释复杂代码、处理 Git 工作流。当它被引入团队或整个组织时如何统一、安全地约束权限、钩子hooks、插件市场与 Bash 工具行为就成为一个核心治理问题。本文以仓库 examples/settings 目录下的三份官方示例配置为骨架逐项拆解settings-lax.json、settings-strict.json、settings-bash-sandbox.json的字段语义与适用场景并结合 examples/mdm 中的 Jamf、Iru (Kandji)、Intune、组策略Group Policy模板给出从本地试验到组织级托管下发的完整落地路径。读完本文你将掌握 Claude Code settings 分层结构、关键管理属性的生效条件以及如何用最小成本把安全基线推送到全员终端。一、settings 文件的定位与分层结构仓库中的三份示例配置被明确标注为主要面向组织级organization-wide部署的起始模板其原文定位是Example Claude Code settings files, primarily intended for organization-wide deployments. Use these as starting points — adjust them to fit your needs.这意味着它们不是某个个人开发者的本地偏好文件而是治理团队、安全团队可以拿来即用的基线模板。这些配置可以被应用到 settings 层级结构settings hierarchy中的任意层级但原文档特别强调了一个关键约束某些属性只有在企业级enterprisesettings 中指定时才生效典型的例子包括strictKnownMarketplaces严格限制可用的插件市场allowManagedHooksOnly只允许托管managed钩子屏蔽用户/项目自定义钩子allowManagedPermissionRulesOnly只允许托管权限规则屏蔽用户/项目自定义的allow/ask/deny规则。从源码结构看这些属性之所以被限定在企业级作用域是因为它们直接影响用户是否可以自行绕过/覆盖组织策略这一安全边界——如果允许普通用户在低层级覆盖它们组织级治理就形同虚设。因此在实际部署时需要将这些属性写入managed-settings.json或 MDM 托管策略而不是仅仅放进个人settings.json。二、三份示例配置能力总览原文档用一张对比表清晰地划定了三份配置的职责边界这是理解整套示例的入口能力settings-lax.jsonsettings-strict.jsonsettings-bash-sandbox.json禁用--dangerously-skip-permissions✅✅屏蔽插件市场marketplace✅✅屏蔽用户/项目自定义权限allow/ask/deny✅✅屏蔽用户/项目自定义 hooks✅拒绝 Web 抓取与搜索工具WebFetch / WebSearch✅Bash 工具需审批✅Bash 工具必须运行在沙箱内✅可以看到三份配置覆盖了三种典型的治理姿态宽松基线lax、严格管控strict、Bash 沙箱专用bash-sandbox。原文档提醒这些示例是社区维护的片段可能存在不支持或不正确的写法配置的正确性最终由使用者自己负责You are responsible for the correctness of your own settings configuration。这一点在引入任何一份配置前都应牢记。三、settings-lax.json最小安全基线settings-lax.json是三个示例中最小的一份完整内容如下{ permissions: { disableBypassPermissionsMode: disable }, strictKnownMarketplaces: [] }它的作用非常聚焦只做两件事。1. 禁用--dangerously-skip-permissionspermissions.disableBypassPermissionsMode设为disable意味着用户在启动 Claude Code 时无法通过--dangerously-skip-permissions参数绕过权限系统。这是企业治理的第一道闸门无论开发者个人多么想跳过确认、全速前进组织都强制要求权限系统保持开启。2. 屏蔽插件市场strictKnownMarketplaces设为空数组[]表示不放行任何已知市场即默认屏蔽插件市场Block plugin marketplaces。结合前面提到的仅企业级 settings 生效约束这一项必须落在企业级配置中才有意义。它的治理意图很明确不允许成员随意安装来路不明的插件从而缩小供应链攻击面。从仓库实际内容看examples/mdm/managed-settings.json也使用了同样的最小策略permissions.disableBypassPermissionsMode: disable说明禁用绕过权限模式是整个示例家族共用的最小公共基线——先从它开始再按需叠加更严格的规则。四、settings-strict.json全面严格管控settings-strict.json是三份示例中字段最全的一份代表能关的都关、能管的都管的严格姿态{ permissions: { disableBypassPermissionsMode: disable, ask: [ Bash ], deny: [ WebSearch, WebFetch ] }, allowManagedPermissionRulesOnly: true, allowManagedHooksOnly: true, strictKnownMarketplaces: [], sandbox: { autoAllowBashIfSandboxed: false, excludedCommands: [], network: { allowUnixSockets: [], allowAllUnixSockets: false, allowLocalBinding: false, allowedDomains: [], httpProxyPort: null, socksProxyPort: null }, enableWeakerNestedSandbox: false } }1. 权限规则ask 与 deny 双管齐下在permissions内除了继承禁用绕过权限模式之外还新增了两组规则ask: [Bash]Bash 工具执行任何命令前都必须请求用户审批Bash tool requires approval。在严格模式下即使是看似无害的 shell 命令也不会被静默放行deny: [WebSearch, WebFetch]直接拒绝 Web 搜索与 Web 抓取工具Deny web fetch and search tools杜绝 Agent 通过联网工具外泄代码、或者从不可信网页抓取内容。2. 只允许托管规则与托管钩子allowManagedPermissionRulesOnly: true屏蔽用户/项目自定义的allow/ask/deny规则。也就是说权限规则的唯一合法来源是组织托管的 settings个人在settings.json、settings.local.json或项目.claude/settings.json中写的规则不再生效allowManagedHooksOnly: true屏蔽用户/项目自定义的 hooks。钩子如 PreToolUse、PostToolUse、UserPromptSubmit 等生命周期回调是强大的扩展点但也可能被用来注入恶意行为严格模式下只信任托管钩子。这两项同样属于仅企业级 settings 生效的属性原文档明确点名allowManagedHooksOnly、allowManagedPermissionRulesOnly因此在测试时不能只放在个人配置里必须放到managed-settings.json或 MDM 策略中验证。3. 内嵌的沙箱骨架值得注意strict 配置也包含了一个完整的sandbox对象但没有设置enabled: true。从源码结构可以推断这份配置的意图是预先声明沙箱参数如网络策略但并不强制启用沙箱。真正把沙箱打开的是下一份settings-bash-sandbox.json。这也印证了原文档 Tips 中的建议可以把不同示例中的片段合并拼出自己想要的最终配置。五、settings-bash-sandbox.jsonBash 专用沙箱第三份配置专门解决一个问题让 Bash 工具必须运行在沙箱之内{ allowManagedPermissionRulesOnly: true, sandbox: { enabled: true, autoAllowBashIfSandboxed: false, allowUnsandboxedCommands: false, excludedCommands: [], network: { allowUnixSockets: [], allowAllUnixSockets: false, allowLocalBinding: false, allowedDomains: [], httpProxyPort: null, socksProxyPort: null }, enableWeakerNestedSandbox: false } }1. 核心开关sandbox.enabled: true强制开启 Bash 沙箱。这是它与 strict 配置最本质的区别allowUnsandboxedCommands: false不允许任何命令逃逸到沙箱之外运行与enabled: true形成必须沙箱、且必须全程沙箱的双重约束autoAllowBashIfSandboxed: false即使命令最终在沙箱内执行也不会被自动放行仍然遵循权限审批流程allowManagedPermissionRulesOnly: true与 strict 配置一致权限规则只信托管来源。2. 网络策略字段sandbox.network提供了细粒度的网络隔离控制字段默认值/示例值含义allowUnixSockets[]允许访问的 Unix socket 白名单空数组表示不额外放行allowAllUnixSocketsfalse是否放行所有 Unix socket默认否allowLocalBindingfalse是否允许在沙箱内绑定本地端口默认否allowedDomains[]允许访问的域名白名单空数组表示默认网络策略httpProxyPortnullHTTP 代理端口null表示未启用socksProxyPortnullSOCKS 代理端口null表示未启用3. 边界与嵌套沙箱excludedCommands: []明确排除在沙箱外的命令列表示例中为空即不豁免任何命令enableWeakerNestedSandbox: false不启用更弱的嵌套沙箱。从命名可以推断这是为了在沙箱内再启动嵌套进程时防止嵌套沙箱被降级为更宽松的约束。4. 必须牢记的边界sandbox 只作用于 Bash原文档用一个专门的 Tips 强调了这个极易踩坑的点Thesandboxproperty only applies to theBashtool; it does not apply to other tools (like Read, Write, WebSearch, WebFetch, MCPs), hooks, or internal commands.也就是说sandbox只约束 Bash 工具本身不会约束 Read、Write、WebSearch、WebFetch、MCP 工具、hooks 或内部命令。如果你的治理目标涉及这些面需要另行通过权限规则如 strict 中的deny列表或托管钩子来覆盖而不是指望一份沙箱配置包打天下。六、组合、测试与本地验证原文档给出了四条非常务实的落地建议逐条展开如下。1. 按需合并片段Consider merging snippets of the above examples to reach your desired configuration——三份配置不是互斥的单选题而是可拼装的乐高积木。例如想要严格权限 强制沙箱取 strict 的permissions.ask/denyallowManagedHooksOnly再叠加 bash-sandbox 的sandbox.enabled: true想要宽松但禁止联网取 lax 的disableBypassPermissionsMode strict 的permissions.deny: [WebSearch, WebFetch]。合并时注意保持 JSON 结构合法、同名字段以最严格的意图为准。2. 保持合法 JSONSettings files must be valid JSON——settings 文件必须是合法的 JSON。这里的文件都是.json后缀不能使用注释JSON 原生不支持注释、尾逗号等非标准写法。逐字照抄示例时尤其要检查引号与逗号。3. 先本地测试再组织分发Before deploying configuration files to your organization, test them locally by applying tomanaged-settings.json,settings.jsonorsettings.local.json——最稳妥的流程是先在单机上的managed-settings.json、settings.json或settings.local.json之一中应用候选配置跑通典型工作流如让 Agent 执行 Bash、访问网络、调用 hooks确认行为符合预期后再推向整个组织。4. 明确沙箱作用域如上一节所述sandbox只覆盖 Bash 工具。测试时务必验证启用沙箱后其他工具的权限行为是否仍符合你的预期例如 strict 模式下 WebSearch/WebFetch 是否被deny正确拦截。七、通过 MDM 组织级下发当配置在本地验证通过后就可以通过 examples/mdm 下的模板把它们变成用户无法覆盖的托管策略。原文档指明这些模板适用于Jamf、Iru (Kandji)、Intune 或组策略Group Policy。所有模板都编码了同一个最小示例permissions.disableBypassPermissionsMode你可以在此基础上替换成自己的完整配置。1. 模板与平台的对应关系文件适用平台/工具managed-settings.json任意平台部署到系统配置目录macos/com.anthropic.claudecode.plistJamf 或 Iru (Kandji) 的 Custom Settings 载荷偏好域com.anthropic.claudecodemacos/com.anthropic.claudecode.mobileconfig完整配置描述文件用于本地测试或接收完整 profile 的 MDMwindows/Set-ClaudeCodePolicy.ps1Intune 平台脚本写入C:\Program Files\ClaudeCode\managed-settings.jsonwindows/ClaudeCode.admx windows/en-US/ClaudeCode.adml组策略或 Intune 导入 ADMX写入HKLM\SOFTWARE\Policies\ClaudeCode\SettingsREG_SZ 单行 JSON2. macOSplist 与 mobileconfigcom.anthropic.claudecode.plist 是最精简的 macOS 模板本质上就是 settings JSON 的 plist 表达dict keypermissions/key dict keydisableBypassPermissionsMode/key stringdisable/string /dict /dict而 com.anthropic.claudecode.mobileconfig 是一个完整的配置描述文件使用com.apple.ManagedClient.preferences载荷类型通过mcx_preference_settings将com.anthropic.claudecode偏好域设置为Forced强制。模板中的PayloadUUID与PayloadOrganization是占位值原文档建议在正式使用前用uuidgen生成你自己的 UUID 并替换。3. Windows平台脚本与 ADMX 组策略Set-ClaudeCodePolicy.ps1 面向 Intune 的平台脚本Platform scripts通道脚本逻辑很直接创建C:\Program Files\ClaudeCode\目录将内嵌的 JSONUTF-8 无 BOM写入managed-settings.json并输出写入路径。Claude Code 在启动时读取该文件并将其视为托管策略源。脚本头注释还提示了 Intune 侧的推荐配置使用登录凭据运行否64 位 PowerShell 主机是。ClaudeCode.admx en-US/ClaudeCode.adml 则是组策略路径ADMX 定义一个名为ManagedSettings的 Machine 级策略注册表项为SOFTWARE\Policies\ClaudeCode值名Settings类型为单行 JSON 文本maxLength1000000ADML 提供本地化文案与输入框说明。其说明文本给出了单行 JSON 的示例{permissions:{disableBypassPermissionsMode:disable}}同时还提示如果配置体积较大或更希望直接管理 JSON 文件可以改用Set-ClaudeCodePolicy.ps1部署C:\Program Files\ClaudeCode\managed-settings.json。4. 部署后的验证要点原文档给出了两个可操作的验证手段在正式推送到全员前先在一台机器上测试用/status命令确认配置来源已出现在Setting sources列表中——macOS 上应显示Enterprise managed settings (plist)Windows 上应显示Enterprise managed settings (HKLM)这类方式部署的 settings 位于优先级的最顶端用户无法覆盖Settings deployed this way sit at the top of the precedence order and cannot be overridden by users。八、从模板到生产推荐落地路径综合原文档 Tips 与仓库模板一个稳妥的组织级落地路径可以总结为四步选基线按治理姿态从 lax最小、strict全面、bash-sandboxBash 专项中选择或按需合并片段本地验证在managed-settings.json/settings.json/settings.local.json中应用跑通真实工作流确认合法 JSON、确认sandbox只影响 Bash、确认企业级属性确实生效单机试部署通过 MDM 或直接放置系统配置目录的方式在单台机器部署用/status确认 Setting sources 正确显示托管来源全员下发按平台选择 Jamf / KandjimacOS plist 或 mobileconfig、Intune平台脚本或 ADMX 导入、组策略ADMX/ADML完成分发并保留修改PayloadUUID等占位值的习惯。这套流程把最小安全基线禁用--dangerously-skip-permissions作为公共起点再按需叠加严格权限规则、托管钩子约束与 Bash 沙箱最终通过 MDM 固化为用户无法覆盖的强制策略——这也正是本仓库 examples/settings 与 examples/mdm 两个目录被设计成互补结构的原因前者回答配什么后者回答怎么发。【免费下载链接】claude-codeClaude Code is an agentic coding tool that lives in your terminal, understands your codebase, and helps you code faster by executing routine tasks, explaining complex code, and handling git workflows - all through natural language commands.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
