claude code auto mode 允许 push main 吗

auto 默认允许向本仓含 default branch 推送；force push、secret 与改历史仍 soft-block，可用 ask/deny 前置拦截。

claude code auto mode 允许 push main 吗

claude code auto mode 允许 push main 吗：默认允许。auto mode 下 Claude 可向当前仓库任意分支推送，包括 default branch（通常是 main 或 master）；v2.1.211 之前 classifier 对 default branch 的 routine push 更窄，现行默认更宽。force push、commit 含 secret、改写 git 历史仍属 soft-block，需你明确点名动作才放行。

作者：CodePass 技术编辑

默认允许的范围

dev.to 当日梳理 引官方文档：auto 允许对「你正在工作的仓库」任意分支 push，并允许创建 PR。分支名若像 deploy 目标（含 production、release、gh-pages 等），分类器会按生产部署单独研判，不能假设「叫 feature/ 就安全」。

这与 8 月 14 默认 auto 同期生效的产品策略一致；背景见 claude code auto mode 默认改什么。生产团队若 default branch 直连发布，应在 GitHub/GitLab branch protection、required review 与 managed permissions.ask 上加层，别只靠「agent 一般不会 push main」的侥幸心理。

v2.1.211 之前 classifier 只允许 working branch、Claude 自建分支、以及对 default branch 的 routine push；现行默认扩大到「本仓任意分支」。若你文档仍引用旧版行为，以 dev.to 引用的当前 docs 为准。PR 创建同样默认允许；draft PR 与 merge 仍受平台权限与 repo 设置约束，classifier 不替你做 code review。

soft-block 的三类 push 相关动作

force push、把 secret 写进 commit、以及 rewrite history（如 aggressive rebase）默认 soft-block。「清理一下仓库」不算明确授权 force push；「force-push 这个分支」才算。聊天里模糊意图不足以清 block，需命名具体动作或在 /permissions Recently denied 里按 r 重试并说清楚。

审批 UI 被 tab 或不可见 Unicode 截断的历史问题，在 claude code 2.1.223 权限修复 有对应补丁；若你仍依赖人眼扫 Bash 再点 Yes，应升到 223 再谈 push 策略。auto 下很多 push 根本不弹窗，UI 截断问题让位给「默认就推了」这一层风险。

secret soft-block 指 commit 内容含疑似密钥；classifier 可能在 push 前拦 git commit 或 push 本身。history rewrite 包括 git push --force、git rebase -i 改已推送历史等。部署型分支名触发额外 scrutiny 时，push 到 release/x 可能比 push 到 feat/x 更容易 deny，即使用户口头说「只是备份」。

用 ask/deny 在分类器前卡住 push

permissions.deny 与 permissions.ask 永远在 classifier 之前评估，显式 ask 不能被 auto 静默批准。示例：

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

团队级永久边界应写 managed settings。聊天里说「别 push 等我 review」分类器能读，但 context 压缩后可能丢； durable 规则比口头约束可靠。客户环境与护栏取舍见 claude code auto mode 生产怎么用。

若只想拦 push 到 default branch 而允许 feature branch，deny/ask 规则要写到具体 ref 或 remote 模式，例如 deny Bash(git push origin main)；wildcard 语法以 permission rules 文档为准。GitHub ruleset 与 Claude permission 是双轨：即使 classifier 放行，平台仍可能拒 push。

窄 allow 规则（如 Bash(npm test)）在 auto 下仍 bypass classifier，只有 Bash(*) 这类宽规则会被搁置。若担心 npm test -- ... 里藏 destructive 参数，可开：

{
  "autoMode": {
    "classifyAllShell": true
  }
}

需 v2.1.193+，用 latency 换「每条 shell 都过 classifier」。tier 与 bypass 逻辑见 claude code auto mode 分类器怎么工作。

自定义 autoMode 列表时别丢掉 defaults

若在 user 或 managed 里改 autoMode.allow、soft_deny、hard_deny 或 environment，数组里须保留字面量 "$defaults"，否则会替换整段内置列表，连 force-push、curl | bash 等 soft-block 一并丢失。改完跑 claude auto-mode config 与 claude auto-mode defaults 核对。

Background session 在 v2.1.220+ changelog 里还会在 worktree 里 commit/push，任务需要时开 draft PR； unattended agent 推 default branch 的场景比交互 session 更多。CLAUDE.md 若写「完成后 push 并开 PR」，auto 默认会执行，除非 ask/deny 拦住。

worktree 隔离阻止 Bash 伤 main checkout，但不阻止「向 remote 的 main 推 commit」；文件树隔离与 git remote push 是两条线。并行 session 各在 worktree 开发，仍可能争同一个 origin/main。

误 push 后的补救与审计

即使用 ask 规则，仍建议 default branch 开 required PR + status check。auto 放行 push 后，回滚靠 git revert 或平台保护，不是 classifier 自动 undo。Recently denied tab 可审计 classifier 曾拦过什么；已放行的 push 不会出现在 denied 列表。

若组织禁用 bypass 但仍见 agent push，查 repo 是否缺 branch protection，或是否有人把 permissions.deny 只写在 local settings 而未进 managed。8 月 14 默认 auto 不会删除既有 deny；新同事无 deny 规则时风险最大，onboarding checklist 应含 push ask。

Monorepo 多 remote 时，classifier 默认按「当前 checkout 所属仓库」判断 push 是否 in-environment；fork 上 push 到 upstream 可能触发额外 deny，需在 autoMode.environment 声明 remote URL。gh pr create 与 git push 是两条 Bash 路径，只 ask 其一可能漏另一。

CI 里若用 claude -p unattended 完成「修测试并 push」，background session changelog 行为会自动 commit/push；与交互 session 相同 default push 规则。CI 账户应在 managed pin ask 或 deny push，而不是假设 headless 更保守。

git push --tags 与 push branch 在 classifier 眼里可能不同风险等级；若 release 流程依赖 tag push 上 default，应单独加 ask。Large force-push 到 shared branch 在 manual 下也要人眼确认，auto 下 soft-block 后仍可能因你明确 retry 而执行，Recently denied 里的 r 等于你承担后果。

对比 v2.1.211 前后：老版本 default branch push 更窄，升级后「允许 push main」 surprise 多来自版本 + 默认 auto 叠加，不是单一 8 月 14 开关。读 release note 时把 git 策略与 permission default 两条线一起看，避免只盯日历日期。

permissions.deny 写 Bash(git push origin main *) 仍可能被更具体的 allow 干扰，规则 precedence 以文档为准；拿不准时用 managed 下发并在 staging repo 试 push。与 claude code auto mode 生产怎么用 里的客户护栏模板对齐时，push ask 通常是第一条，因为 auto 默认最常被忽视的就是 default branch。

submodule 与 subtree 仓库的 push 边界更模糊：classifier 按当前 checkout 判断 in-environment，嵌套 repo 的 remote 可能不在默认可 push 列表。多 repo monorepo 工具链应在 CLAUDE.md 写明允许 push 的 remote 列表，或统一 deny 所有 push 改由 CI 执行。

gh pr merge 与 git push 风险不同：前者可能触发 CI 合并进 default，classifier 对 PR 流程的判断与裸 push 不完全相同。高合规环境可 deny 整条 gh * 子集，只留 gh pr view 等只读命令，再让 CI bot 执行 merge。

fork 工作流里 push 到 origin（自己的 fork）通常 in-environment，开 PR 到 upstream 则走 gh pr create；只 deny push 不 deny gh pr create 时，agent 仍可能把改动送到 upstream 审查队列，只是不直接 push upstream default。按你的 Git 流程选 ask 点，别照搬示例 JSON。

参考资料