我每天怎么用 Claude Code：tmux、权限模式和我的手机

Claude Code 是 Anthropic 的编程 agent。它跑的是和 Claude 应用一样的 Claude 模型，只不过是在你自己的机器上，能读你的文件、跑 shell 命令、改你的代码，付费的 Claude 套餐都带它。我是在终端里用它，而不是 VS Code 扩展或桌面应用：笔记本上一个 tmux session 里开着五个 session，几乎全是关掉权限提示启动的，在手机上可以通过 Claude 应用的 Remote Control、SSH 或一个聊天机器人连过去。

下面就是这套配置的细节，数字来自我自己的机器，而不是凭记忆：设置文件、Claude Code 存放在 ~/.claude/projects 下的 session 记录（我的最早到 8月28日），还有它的 prompt 历史，最早到 2 月，一共 7,323 条 prompt。

Claude 和 Claude Code 不是一回事

#

Claude 是一个模型家族，也是你跟这些模型对话的那个聊天应用：claude.ai、桌面端和手机上的都是。Claude Code 是建在这些模型之上的 agent。你在一个项目文件夹里启动它，它就在那儿循环干活：读文件、跑命令、改代码、跑测试，直到活干完，或者需要你出面。问 Claude 怎么修一个问题，你得到的是一个回答。问 Claude Code，你得到的是修好的代码，外加一份等你看的 diff。

两个我都用。从 10月18日起，我做的一个集市兼社区应用就从 Django 后端直接把翻译请求发给 Claude API，而把它切换过去的那次改动，就是在一个 Claude Code session 里做的。在我的 session 记录里，94% 的回复来自 Opus 5.5，我设置里的 effort 级别是 high。

原生安装程序只有一行，而且会自己更新：

curl -fsSL https://claude.ai/install.sh | bash

它会在 ~/.local/bin 里留下一个 claude 符号链接，指向 ~/.local/share/claude/versions/；我的在 10月21日自己从 2.1.305 升到了 2.1.306。Claude Code 需要付费的 Claude 套餐（Pro、Max、Team 或 Enterprise），或者一个 API 账号。价格变得太勤，我就不写了，请看 Anthropic 的价格页面。

一个 tmux session，七个窗口

#

写这篇的时候，tmux list-panes -a 显示我笔记本上只有一个 session，叫 main，里面有七个窗口。其中五个是 Claude Code，每个项目一个：我的集市应用和我的估价应用（两个都在我现在的技术栈里介绍过）、这个博客，还有两个小东西。我的终端 profile 打开每个窗口时都会起一个登录 shell，并把它接到 main 上。所以在笔记本上新开一个标签页，和从手机 SSH 登录进来，落到的是同一批 session。

9月17日到 10月8日，我试过另一个终端多路复用器，后来回到 tmux，原因很实际：我手机上的 SSH 应用是用 tmux 做多路复用的，它的快捷按钮发的也是 tmux 的默认按键。~/.tmux.conf 里类似下面这几行，就是为手机写的：

set -g prefix C-a                 # Ctrl-a prefix
set -g prefix2 C-b                # stock Ctrl-b too, for apps that send it

# Size each window to the client that used it last, not the smallest one,
# so a phone attached to the same session doesn't shrink it.
setw -g window-size latest

# Copy to the clipboard of whichever terminal is attached (OSC 52),
# so over SSH it lands on the phone's clipboard too.
set -g set-clipboard on

在 tmux 里，有两件事会不一样。Claude Code 用 Ctrl+B 把正在跑的命令放到后台，而 Ctrl+B 现在是我的第二个 tmux prefix，所以 ~/.claude/keybindings.json 把它关掉，改用 Meta+B：

{
  "bindings": [
    { "context": "Global", "bindings": { "ctrl+b": null } },
    { "context": "Task", "bindings": { "ctrl+b": null, "meta+b": "task:background" } }
  ]
}

另一件是换行。按 Enter 会发送 prompt。文档说，\ 加 Enter，以及 Ctrl+J，是在任何终端里都能用的两种；Option+Enter 要等终端把 Option 当作 Meta 发送之后才能用；Shift+Enter 在有些终端里原生就能用，但 tmux 只有在开了 extended-keys 时才会把它传过去。我没开，所以在我的 session 里，Shift+Enter 就是发送 prompt。这些我其实很少用到：7,323 条 prompt 里，只有 84 条含有我手敲的换行，而有 279 条含有粘贴的内容。Claude Code 会把粘贴折叠成 [Pasted text #1 +34 lines] 这样的占位符，发出去的还是全文。

终端、VS Code 扩展还是桌面应用？

#

同一个 agent 有好几种外壳，它们读的是同一套设置文件。按 Claude Code 在每份 session 记录里记下的入口来算，我的 session 是这么分布的：

对我来说就是终端，而且不是出于情怀。我手机要接上去的 tmux 需要终端，channels 也需要。channels 能把外部事件推进一个 session，文档把它列为 CLI 的功能。

也常有人问 Claude Code 需不需要 git。CLI 不需要：我的 home 目录不是仓库，而我有 208 条 prompt 发给了在那里启动的 session。桌面应用的文档说，它的 session 隔离需要 git，每个 session 有自己的 worktree；把云端 session 拉到终端里，也需要同一个仓库的 checkout。“Git is required for local sessions” 这条提示我自己从没见过。我最近一次用桌面应用是 10月20日，那个 session 跑在一个根本不是仓库的文件夹里。

权限模式，以及我实际用的那个

#

权限模式决定 Claude Code 多久停下来问你一次，用 Shift+Tab 在各个模式之间切换。Manual（default）在大多数编辑文件、跑命令或访问网络的操作之前都会问。acceptEdits 放行文件编辑和常见的文件系统命令。plan 只读、只提方案，不做编辑。auto 让第二个模型，也就是一个分类器，去拦下有风险的操作，而不是来问你。bypassPermissions 几乎什么都不问。从 2.1.283 版开始，终端里的 session 默认以 auto 模式启动，除非你另行指定。

所以"怎么让 Claude Code 不问权限就跑"，我的老实回答是：我就是这么启动它的：

claude --dangerously-skip-permissions

我 shell 历史里的 69 条 claude 命令，有 62 条带着这个 flag，现在在跑的五个 session 也全都带着。8月28日到10月21日之间我敲的 1,266 条 prompt 里，1,179 条发给了 bypass 模式的 session，82 条给了 auto 模式，5 条给了 Manual 或 accept-edits。

文档说得很直白，bypass 模式是给"容器、虚拟机或不联网的 dev container 这类隔离环境用的，在那里 Claude Code 损坏不了你的宿主系统"。我的笔记本哪种都不是，而且我的设置里记着我已经点掉了那条警告（"skipDangerousModePermissionPrompt": true）。如果你也这么做，要知道 allow 规则在 bypass 模式下不起作用，所以在我日常的 session 里，分散在 19 个设置文件里的 378 条 allow 规则完全是摆设。deny 和 ask 规则仍然生效，而这两种我一条都没有。

例外是那个要读别人说的话的 session。它的启动脚本不带这个 flag，所以它以 auto 模式启动。10月12日到20日之间到达 session 的 27 个生产环境事件，全部是在 auto 模式下到的，43 条聊天消息里也有 42 条是，没有一条落在 bypass 下。

真正让 bypass 模式没反咬我一口的，是几条习惯，都是出过事以后才写进 Claude 的记忆里的。9月10日，几个 session 在那个集市应用的同一个 checkout 里干活，一个一行的修复挺过了四次失败的构建，却在 commit 之前没了：另一个 session 覆盖了那个文件，而 git 里没有任何记录。同一天，一次部署差点把某个 session 还没 commit 的改动发出去，因为部署脚本构建的是工作区，不是 HEAD。从那以后的规矩是：小修复一能用就马上 commit；按文件名 stage，永远不用 git add -A；看看 git status 里有没有不是你做的改动；当 main 上有其他 session 还没部署的改动时，从线上那个 commit 建一个 worktree 来部署。

从手机上连过去

#

有三条路，每条通到的东西都不一样。

Remote Control 把手机上的 Claude 应用，或者浏览器里的 claude.ai/code，连到一个一直在笔记本上跑着的 session，文件、工具和 MCP server 都在。9月13日到10月20日之间，我敲了 26 次 /rc。现在 remoteControlAtStartup 开着，新 session 会自己连上：10 月初以来我启动的 77 个 session 里，有 67 个带 Remote Control 链接，而 9 月下半月是 52 个里只有 3 个。开着 agentPushNotifEnabled 的话，Claude 觉得有必要时可以发推送通知，文档说通常是长任务跑完，或者需要你拿主意的时候。它需要 claude.ai 的订阅，而不是 API key；而且因为 session 跑在笔记本上，笔记本必须醒着。从 10月15日起，我的笔记本合上盖子也不睡了（sudo pmset -a disablesleep 1）。

反过来也行。/teleport，或者 claude --teleport，可以把在网页或应用里启动的云端 session 拉到终端里，连同它的分支和对话一起。我这么做过两次，都在 7 月。

SSH 是我想要终端本身的时候用的。手机通过我那篇私有网络的文章里的私有网络连到笔记本，一个别名再把它接到 main 上，于是我可以在留在笔记本上的那些窗口之间划来划去。让 Mac 正常响应手机上的应用，前后修了四个地方，其中跟 Claude Code 有关的是：tmux 绝不能自己启动。有个应用开了个 session 想跑 docker ps，拿回来的却是 72 KB 的屏幕重绘。

聊天机器人是给那个我不想守在旁边看的 session 用的。从 10月12日起，有一个 session 带着我写的一个小 channel 在跑，它每分钟查一次应用的服务器有没有新的生产环境报错和项目看板动态，然后交给这个 session；另外还加载了一个官方的聊天插件，这样在它 allowlist 上的我们两个人就能给它发消息。启动的那一行大致如下，名字都换成了通用的：

exec claude \
  --channels plugin:<chat-plugin>@claude-plugins-official \
  --dangerously-load-development-channels server:my-events "$@"

一个 supervisor 脚本让它一直在 tmux 里跑着。重启之后它会接着原来的对话，所以 session 是接着干，而不是一觉醒来脑子一片空白；每次重启它都会在聊天里通报一声。这个 session 在工作区里修东西，修完就停，只有一个例外，是我 10月13日加的：如果一个 bug 真的在生产环境伤到了用户，它可以修复、测试、commit 并部署，然后告诉我们它做了什么。

Skills、记忆和 /goal

#

我的设置文件里没有一个 hooks 键。最接近的是 /goal，从 7月11日起我用了 279 次。它接受一个条件，为这个 session 设一个 Stop hook，用 Claude Code 自己的话说，这个 hook “在条件满足之前会阻止停止”。我写的 goal 读起来就跟我嘴上说的一样。一条 7 月的真实例子，错别字原样保留，告诉它构建 “still broken, try a deeper fix and dont stop until”（还是坏的，往深里修，别停），直到发到测试人员手上为止。想看看长任务进展如何、又不想打断它，可以用 /btw，它问的是一个不进入对话的旁支问题。我问的大多是某种版本的 “hows it going?"（进展如何？）。

Skills 装的是那些不然我每次都得重新解释一遍的东西。有一个用户级的 skill，读我维护的几个网站（这个博客也在其中）的每周关键词报告，再把结果用到标题、描述和标签上。这篇文章回答的那些问题，就来自它给这个博客出的、日期为 10月18日的那份报告，而这个 skill 文件和它的代码一起放在一个仓库里做版本管理。那个集市应用的仓库有自己的 skills：一个在 Docker 里启动 API 并跑冒烟测试，一个处理项目看板，还有一个负责提交公司的费用报销。我装的两个插件，一个是 Swift 的语言服务器插件，另一个就是那个聊天插件。

记忆是存放教训的地方。我在 17 个项目里一共有 160 个记忆文件，其中 83 个属于那个集市应用，很多都跟某次出故障有关。这个应用的 CLAUDE.md 现在大约是 6 月时的六倍长。这个博客的 CLAUDE.md 则是个空文件；一篇文章该是什么语气，写在一个记忆文件里。

遇到更大的活，Claude 会启动 subagent，在我的主 session 里一共 120 次，其中 40 次是对话的 fork。这个博客的日文、韩文、中文和越南文版本就是这么来的。10月19日和20日，这个应用社区板块的改版前后四次过了 Workflow 工具：一次从七个角度加一个 critic 做的审查，确认了大约 58 个问题；五个小组分头修复，每组只负责自己的文件，修完各自经过评审；一轮收拾剩下的问题；最后一次独立检查，确认每个问题都修好了。它在 20 号上线。

devbox 在哪儿派上用场

#

我那篇私有网络的文章讲的是把重活放到 devbox 上，也就是办公室里那台带 GPU 的工作站，再从哪儿都能连过去。这些"连过去”，大多是 Claude Code 在做。9月24日到10月19日之间，笔记本上的 21 个 session 通过普通的 ssh 在 devbox 上跑了 1,470 条命令：kubectl 进那上面跑着的集群，在一个数据库 pod 里跑 psql，用 tmux capture-pane 看看一个长任务跑到哪儿了。因为离开办公室网络时 ssh devbox 会退回到一条隧道，同一个 session 在办公室、在家、在咖啡馆都能用。而且笔记本不再睡眠，session 可以一直操控着 devbox，我就在手机上时不时看一眼。

Claude Code 还是 Codex？

#

凭我自己的使用经验，我没法告诉你 Claude Code 是不是比 Codex 好，看这张表就知道为什么：

一周里四个 thread，一个关于图片的问题、对一个网站的两次改动、一个 3D 场景，这叫试用，算不上比较。不过其中有个细节，换任何 agent 时都用得上。那个 3D 项目把规则放在一个 claude.md 里，我在那儿问 Codex 的第一个问题，就是它在对话开始前会不会读 Claude 的文件。它说不会，直到我让它去读那个文件，它才知道项目的规则。不管你换到哪个 agent，说明文件都会留在原地，除非你自己把它带过去。从那以后我再没开过 Codex 的 thread。9月24日到10月4日之间，有那么几天这个扩展在 VS Code 里加载过，但我一个 thread 也没开，现在它已经卸载了。

所以我能站得住的结论很窄。我的整套配置是围绕 Claude Code 搭起来的，而我也没有回头去看现在的 Codex 处理同样的事情会怎么样。

最后一个数字，比上面任何内容都更能说明我是怎么用它的。8 月下旬以来，在我笔记本上的主 session 里，Claude Code 跑了 18,311 条 shell 命令，读、写或编辑文件 2,331 次。按次数算，它的大部分工作是在跑那些本来要我自己敲的命令，在笔记本上，也通过 SSH，不管我人在哪儿。而它真写起代码来，那些代码也不是到哪儿都受欢迎，这是另一个故事了，见 pyhtml2text 那篇。