用 Claude Code Auto Mode + Telegram Channels 远程跑写码、测试与调试闭环

人在外面，Claude Code 会话跑在家里的电脑或远程主机上，手机通过 Telegram 发指令，任务结束后再收一条总结消息——这套链路是能跑通的。

要让它真正可用，需要两个条件同时成立：

• Channels 把 Telegram、Discord 或 iMessage 的消息转进正在运行的 Claude Code 会话
• Auto Mode 去掉频繁的人工确认，让长任务不中途卡死在权限提示上

这篇直接把关键点讲清楚：什么场景适合这样用，Auto Mode 到底替代了什么、没替代什么，以及从零开始把 Telegram 通道配起来。

先看前提条件

如果要复现这套流程，环境至少满足下面这些要求：

• Claude Code v2.1.83 或更高版本
  • Auto Mode 需要 v2.1.83
  • Channels 需要 v2.1.80
• 已安装 Bun runtime
  • 所有 Channels 插件都依赖 Bun
  • Node 和 Deno 都不行
• Claude 账号具备以下之一：
  • Max
  • Team
  • Enterprise
  • 或 API 访问权限
• Auto Mode 不支持 Pro
• 即使购买 extra-usage 或附加包，也不能开启 Auto Mode
• 手机上有 Telegram 账号
• 宿主机安装 Python 3.10 或更高版本
• 有一台在你离开后仍能保持运行的机器
  • 笔记本别合盖
  • 台式机别休眠
  • 或者直接用服务器

Auto Mode 到底解决了什么

Claude Code 默认会在执行“超出项目目录内普通读写”的动作前要求确认。现实里，大多数确认最后都会被点掉。统计数据里，这类提示的批准率达到 93%。既然大多数都放行，频繁弹框带来的更多是摩擦，而不是额外安全性。

Auto Mode 的做法不是“彻底跳过权限”，而是把权限判断交给一个独立分类器：

• 每一次工具调用会被单独审查
• 负责审查的模型是独立于主写码模型之外的 Sonnet 4.6
• 它只做一件事：允许或阻止本次调用

这样一来，长时间无人值守的任务就不会每隔几十秒停一次。

它的安全模型不是单层的

这套机制至少有两层防护：

1. 工具调用分类器
   • 负责判断某次 shell、网络、目录外文件访问、子代理调用等动作是否应该放行
2. 工具输出探针
   • 对文件内容、网页抓取结果、shell stdout 等输出进行扫描
   • 目的不是审计正确性，而是挡掉 prompt injection 一类输入污染，再决定是否进入 Claude 的上下文

关键点在于：主模型和分类器不是同一个模型。主模型即便被误导，也不能直接“说服”分类器放过危险操作。

哪些动作会走分类器，哪些不会

不是所有操作都要审查。

直接快路径放行的操作

以下动作通常不需要分类器介入：

• 读取文件
• 文本搜索
• 代码导航
• 项目目录内的文件编辑

会送进分类器的操作

以下动作会被分类器判断：

• shell 命令
• 网络请求 / web fetch
• 项目目录外文件操作
• 启动 subagent

这也是为什么 Auto Mode 适合“在自己项目里持续改代码”，但不意味着它适合对敏感环境完全放权。

Auto Mode 不等于人工复核

这点要说死：Auto Mode 比 --dangerously-skip-permissions 安全得多，但它不等于人工审查。

公开数据里有两组数字值得记住：

怎么解读：

• 把 --dangerously-skip-permissions 换成 Auto Mode，收益很明显
• 但拿 Auto Mode 去替代高风险仓库里的人类 review，不够

17% 的漏报率，换句话说就是大约 六次风险动作里会漏掉一次。这不是“可忽略不计”的级别。

连续拦截后会把控制权还给人

当分类器阻止某次调用时，Claude 会把“被拒绝”当作工具结果继续处理，尝试寻找更安全的替代路径，而不是强行绕过。

但它不是无限重试：

• 连续被拦 3 次，或
• 累计被拦 20 次

Auto Mode 会把控制权交还给人。

如果是无头运行的 claude -p，则会直接终止。

Auto Mode 和 bypassPermissions 的差别，不只是安全性

很多人会把 Auto Mode 理解成“更聪明的 bypassPermissions”。这只对了一半。

bypassPermissions 的问题

bypassPermissions 的核心问题很简单：放得太开。

它可能直接放过：

• 读取 .env
• 编辑配置
• 各类潜在破坏性动作

Auto Mode 默认会对敏感文件操作和显式删除动作更谨慎。一个实用细节是：如果提示里明确点名了某个文件，分类器更可能允许对应编辑。这比“完全无差别放行”要稳得多。

更大的变化：它改变了工作流节奏

Auto Mode 不是单纯权限模式，更像是决策模式。

以前在 bypassPermissions 下，可以把一串技能链成流水线，然后在阶段切换时被提示打断。那个停顿本身就是 review 点：看一眼结果，决定继续还是修正。

切到 Auto Mode 后，这个 review 点会消失。Claude 会自己判断信息是否足够，然后继续下一步。

这件事有明确取舍：

• 想要速度，会喜欢它
• 依赖阶段性人工确认的人，会觉得少了抓手

另一个容易忽略的点：Claude 更敢改自己的配置

在 bypassPermissions 下，Claude 对修改自己的配置、技能文件往往还会额外谨慎，未必真照做。

在 Auto Mode 下，自维护能力反而更强：

• skill 文件
• .claude/ 目录设置
• 自身配置

这些都可能被直接编辑而不再询问。

如果你正希望它维护自己的技能，这很方便；如果你默认“它不会碰自己的配置”，那就是风险点。

各种权限模式怎么选

Claude Code 提供的模式大致落在“全部人工确认”到“几乎不问”之间。

一个实用建议：

• 敏感仓库：用 default
• 自己的普通项目：优先 auto
• 隔离容器 / 一次性 VM：才考虑 bypassPermissions

为什么远程通道下更适合 Auto Mode

Channels 本质上是 MCP 服务器，把外部聊天工具里的消息注入到正在运行的 Claude Code 会话中。

以 Telegram 为例，流程是：

1. 手机给 bot 发消息
2. 插件把消息转发进宿主机上的 Claude Code 会话
3. Claude 在本地文件和本地工具上工作
4. 回合结束时，通过 bot 把结果摘要发回手机

有个关键限制：只有回合结束时才会收到回复。

没有：

• 中途流式输出
• 实时工具调用列表
• 主机侧 live preview

也就是说，在通道模式下，回合执行期间发生了什么，手机端是看不到的，只能等总结回来再知道。

这直接抬高了权限模式的重要性。

为什么 default 不适合真正的远程构建会话

理论上，default 和 acceptEdits 也能把权限提示转发到手机上，你可以在 Telegram 里回复 yes 或 no。

少量提示没问题，真正进入“写代码 → 安装依赖 → 跑测试 → 修 bug”的闭环后，确认会非常多。一路点下去，很快就失去意义。

为什么 --dangerously-skip-permissions 更糟

在终端里开 bypass，至少还能盯着实时输出，必要时按 Esc 中断。

但放到 Telegram 通道里，实时观察能力没了。你发出去一个指令，只能在回合结束后看到结果。中间如果真跑了危险命令，没有任何即时提醒。

Auto Mode 正好卡在中间位置

• 没有权限弹窗轰炸
• 明显危险的操作由分类器挡掉
• 回合结束时会给你一份可复查的结果摘要

远程开发里，这个平衡点是比较合理的。

用一个小项目看这套流程

演示项目是一个叫 libcache 的 Python CLI：

• 从 OpenLibrary API 拉取图书元数据
• 缓存到 ~/.cache/libcache/

技术栈故意选得很朴素：

• uv 管依赖
• typer 做 CLI
• httpx 发请求
• pytest 跑测试

这个项目适合演示，原因有三个：

1. 多文件
   • 在 default 模式下，从零搭起脚手架会堆出一串权限提示
2. 有 HTTP 边界
   • 分类器确实需要对外部调用做判断
3. 规模小
   • 可以在一个 Telegram 回合里做完

搭建步骤

这套东西按顺序配：

1. 宿主机保持唤醒
2. Telegram 插件安装并配对
3. 启动时开启 Auto Mode 和 Channels

有一项没做好，后面都跑不顺。

先把宿主机准备好

Claude Code 是本地进程。机器睡眠后：

• 会话不再接收事件
• Telegram 插件无处投递消息
• 远程控制就断了

macOS 防睡眠

开一个单独终端执行：

caffeinate -d

-d 用来阻止显示器休眠。

Linux 防睡眠

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

恢复时用 unmask 即可。

长时间运行时建议放进 tmux

如果会话要跨窗口、跨 SSH、甚至跨半天以上，直接上 tmux。

新建会话：

tmux new -s claude

之后在里面启动 Claude。需要暂时离开时：

• 按 Ctrl+B
• 再按 D

重新接回：

tmux attach -t claude

提前完成所有 CLI 登录

任何 Claude 可能从 Telegram 侧调用的 CLI，都必须在宿主机上先登录好。手机端没法替你完成交互式认证。

先检查 GitHub CLI：

gh auth status

如果没登录：

gh auth login

同理，其他你可能会用到的工具也应该提前搞定，例如：

• aws
• gcloud
• docker
• 各类包仓库 CLI

安装并配置 Telegram 插件

先装 Bun

macOS 或 Linux：

curl -fsSL https://bun.sh/install | bash

Windows：

powershell -c "irm bun.sh/install.ps1 | iex"

确认版本：

bun --version

在 Telegram 里创建 bot

打开 BotFather，发送：

/newbot

然后按提示设置：

• 一个显示名称
• 一个以 bot 结尾的用户名
  例如：libcache_dev_bot

BotFather 会返回一个 token，把它记下来。

在 Claude Code 中安装插件

/plugin install telegram@claude-plugins-official

如果提示 marketplace 里没有这个插件，先手动添加：

/plugin marketplace add anthropics/claude-plugins-official

然后再试安装。

安装完成后重载插件：

/reload-plugins

写入 Telegram bot token

/telegram:configure <your_bot_token_here>

token 会被写入：

~/.claude/channels/telegram/.env

这里要彻底重启 Claude Code

执行完 /telegram:configure 后，不要只靠 /reload-plugins，直接完整退出再启动：

• Ctrl + D
• 或 /exit

原因很简单：首次 DM 时，配对码显示并不总能通过热重载可靠出现。直接重启最省事。

Telegram 端与会话配对

重启后，在 Telegram 里打开刚才的 bot，发送：

/start

bot 会回一个 6 位配对码。

回到 Claude Code，执行：

/telegram:access pair <code>

这一步是双向确认：两边都要同意，会话才会接受来自 Telegram 的消息。

把 bot 锁到自己的账号

最后一步很重要：

/telegram:access policy allowlist

开启后，不在 allowlist 里的任何账号给 bot 发私信，都会被静默丢弃，也拿不到配对码。

启动时同时开启 Channels 和 Auto Mode

进入项目目录后，直接这样启动：

claude --channels plugin:telegram@claude-plugins-official --permission-mode auto

如果会话已经启动，也可以中途切到 Auto Mode：

• 连续按 Shift+Tab
• 直到状态栏显示 auto

如果想让 Auto Mode 成为默认模式，在 ~/.claude/settings.json 里加上：

{ "permissions": { "defaultMode": "auto" } }

Auto Mode 会主动丢弃过宽的 allow 规则

进入 Auto Mode 时，Claude Code 会从 settings.json 里临时去掉一些太宽泛的允许规则，例如：

• Bash(*)
• Bash(python*)
• 全量 Agent allow

退出 Auto Mode 后，这些规则会恢复。

但窄规则会保留，例如：

• Bash(pytest)

这是个好设计：明确收窄你已经审过的工具，不让通配符把分类器架空。

配好后先做两个验证

至少验证两件事：

1. 给 bot 发一句随便什么，确认手机能收到回信
2. 让 Claude 在项目里写一个小文件，确认不会弹权限提示

这两步都通，说明链路基本没问题。

实际运行时是什么体验

这套流程最适合那种在 default 模式下会弹十几次确认的任务。

比如直接从 Telegram 发这样的需求：

Create a Python CLI that fetches book metadata from OpenLibrary and caches it to disk, use uv for deps, typer for the CLI, httpx for requests, pytest for tests, scaffold the directory and add a README, and when you're done, summarize what you built in under 80 words.

最后加一句“用 80 个词以内总结”，是个很实用的手机端习惯。手机适合看摘要，不适合刷长终端输出。

一个提示会触发很多工具调用，但不需要逐个确认

消息会以类似下面的形式进入宿主机会话：

← telegram · <sender>: ...

之后发生的事大致是：

• 项目内文件写入走快路径，不进分类器
• 依赖安装会进分类器
• 首次 pytest 会进分类器
• 结尾的 git init 也会进分类器

默认情况下，如果动作合理，整个回合会一口气跑完，中间不暂停。

手机上的唯一反馈是“回合结束总结”

这很重要：总结不是实时状态，而是 Claude 对刚完成工作的叙述。

因此验证动作应该尽量显式。别只问“好了没”，更好的方式是要求它拿出证据。

例如：

uv run pytest -v

还可以让它：

• cat 某个具体文件
• 给出文件大小
• 给出行数
• 返回最近提交记录

比如：

git log --oneline

在 Auto Mode 下，做这些验证的成本不高。既然手机上看到的是“结果摘要”，就应该多让它返回可核对的原始信息。

真正连到外部系统也没问题

如果宿主机上 gh 已经完成认证，完全可以从手机发：

push libcache to a new public GitHub repo called libcache, clean commit, decent message, send me the URL when it's up.

Claude 会调用已经登录好的 gh CLI，创建仓库、提交代码、推送，然后把仓库 URL 发回来。

这时“远程开发”就不只是看文件了，而是能真正推动外部系统状态变化。

Auto Mode 什么时候会拒绝继续

Auto Mode 的“推回去”大致有两类。

一类是分类器的硬拦截

会直接硬拦的典型模式包括：

• curl | bash
• 对 main 分支强推
• 云存储批量删除

另一类更常见：Claude 自己识别到动作不可逆

这类不是分类器硬拒，而是模型主动暂停。

在手机端看起来，它不会弹一个红框，也不是系统级 modal，而是正常文本消息，里面会：

• 说明它准备做什么
• 列出将执行的命令
• 要求你回复一个特定确认短语

不是简单的 yes/no。

比如你发出“删掉项目，再把 GitHub 仓库也删了”这种请求，它通常会停下来，列出命令，并提供更温和的替代方案：

• 只删本地
• 只删远端
• 改成 archive

这种停顿是合理的，而且即便这个仓库就是它十几分钟前刚创建的，也不会因为“会话里已经做过相关操作”就自动视为默认同意。

遇到交互式认证，Auto Mode 不会替你硬闯

一个很典型的场景是：删除 GitHub 仓库时，当前 gh token 没有 delete_repo scope。

这时它不会试图绕过认证，而会停下来，要求你在终端手动执行：

gh auth refresh -h github.com -s delete_repo

浏览器登录流、交互授权流，本来就不该指望手机远程自动完成。

拦截累计过多，控制权会回到人手里

同样适用前面的阈值：

• 连续 3 次被拦
• 或累计 20 次被拦

之后 Auto Mode 会结束“自己决定”的状态，把控制权交回人。

当前已知问题

这套链路不是完全没坑，至少有两类问题需要提前知道：

1. Claude Code 在 REPL 提示符空闲时，消息有时不会成功送达
   • 跟踪问题：#48404
2. 插件有时在回复一次后，不再继续转发新消息，除非人为“戳一下”或重启会话
   • 跟踪问题：#36477

现阶段的临时绕法主要是：

• 让会话保持有任务在执行
• 或直接重启会话

这两个问题都还没有修复。

怎么调 Auto Mode 的安全规则

默认规则对大多数“自己的代码仓库”已经够用。如果确实要加固或放宽某些项目边界，先别急着从零写规则，先把内置配置打印出来：

claude auto-mode defaults

它会输出内置的 allow / deny 规则 JSON。

正确思路是：

• 在基线之上扩展
• 不要完全推倒重来

原因很直接：每删掉一条确定规则，就多让分类器临场判断一次；每多一次判断，就多一次漏报机会。

在 settings.json 里加项目级规则

项目特定规则放在 settings.json 的 permissions 下。

进入 Auto Mode 后：

• 窄 allow 规则会保留
• 宽 allow 规则会被丢弃

比较合适的写法像这样：

• Bash(pytest)
• Bash(gh pr create *)

经验上，规则应尽量收窄到“项目真的会用到的那一个工具模式”，少用通配。

如果你过去靠权限提示做阶段性 review

那就别默认 Auto Mode 会替你保留这些检查点。

可选做法有两个：

1. 给关键工具模式或路径显式加 ask 规则
2. 直接改用 acceptEdits
   • 保留 shell / 网络等操作的人工确认
   • 只让项目内编辑自动放行

会话里声明边界，也会影响分类器判断

一个很容易低估的特性是：对话里明确说出的边界条件，会被当成阻止信号。

例如先告诉 Claude：

don't push until I review

即便默认规则允许，后续匹配的 push 动作也可能被拦下来。

这对于一次性会话很好用，比专门去写正式规则轻得多。

查看最终生效配置

如果要确认 settings.json 与默认规则合并后的结果：

claude auto-mode config

企业管理员可以组织级禁用

组织托管设置里可以通过下面这个项直接关掉 Auto Mode：

permissions.disableAutoMode: 'disable'

这套方案适合谁，不适合谁

适合：

• 自己的项目
• 需要长时间跑构建、测试、调试
• 人不在电脑前，但宿主机在线
• 能接受“回合结束后看摘要，而不是实时盯过程”

不太适合：

• 高敏感仓库
• 强依赖逐步人工审查的流程
• 大量不可逆操作
• 还没把宿主机 CLI 认证、睡眠策略、tmux 等基础设施准备好

一句话总结：Auto Mode + Channels 让 Claude Code 从“坐在终端前操作的工具”变成“可异步驱动的本地执行代理”，但它的边界仍然是工具，不是托管运维系统。

常见问题

Auto Mode 是什么

Claude Code v2.1.83+ 提供的一种权限模式。它会用独立分类器模型 Sonnet 4.6 审查每次工具调用，决定放行还是阻止，从而避免长时间无人值守任务卡在确认提示上。

它和 --dangerously-skip-permissions 有什么区别

bypass 基本是全放，除了受保护路径，没有分类器，也没有安全兜底。Auto Mode 会对关键调用做审查，默认拒绝敏感文件操作，并在拦截过多时把控制权还给人。

Channels 是什么

基于 MCP 的插件机制，可以把 Telegram、Discord、iMessage 之类的消息转进正在运行的 Claude Code 会话。你在聊天工具里发消息，宿主机会话接收并执行，回合结束后再把答复发回去。

哪些套餐支持 Auto Mode

支持范围是：

• claude.ai Max
• Team
• Enterprise
• 或 API 访问

不支持 Pro，也不能靠附加包解锁。

它能安全用于任何项目吗

不能这样理解。对个人项目通常足够实用，但它不是人工审查替代品。现有数据里，风险动作漏报率是 17%，所以对敏感仓库，仍然应优先使用 default 模式。

关于

关注我获取更多资讯

📢 公众号

💬 个人号