Claude 后台 Bash 命令：让 dev server 边跑边对话

写代码时经常碰到这种场景：dev server 必须开着才能验证改动、测试套件跑要 5 分钟、构建产物要后台编译——但同时你又想继续和 Claude 讨论下一步怎么改。如果 Claude 一执行 npm run dev 就卡在那里输出日志，整个对话就停摆了。

Claude Code 提供了好几种方式来处理这种”边跑边聊”的需求：内置 Bash 工具的后台模式、! 前缀直接执行 shell、tmux 配合、脚本化打包后台任务。这篇文章把这些手段串起来讲清楚。

在 Claude 对话里跑 bash 的几种方式

方式一：让 Claude 用内置 Bash 工具

最常见的场景：你说”跑一下测试”，Claude 调用 Bash 工具执行 npm test：

> 跑一下测试看看哪里挂了
[Claude 用 Bash 工具执行 npm test]
[输出回到对话里，Claude 接着分析]

Claude Code 的 Bash 工具默认前台执行——命令运行结束才返回控制权。这对短命令（grep、ls、git status）没问题，但对长跑命令（dev server、watch 模式）就会卡死。

方式二：! 前缀手动执行 shell 命令

在输入框里以 ! 开头，整行作为 shell 命令直接执行（不发给 Claude）：

> !ls src/
src/main.go  src/utils.go  src/config.yaml

> !git status
On branch main
nothing to commit, working tree clean

> !npm test
... 测试输出 ...

! 前缀让你无需切出 Claude Code 就能跑 shell 命令。命令的 stdout 显示在对话区，但不会进入 Claude 的上下文——Claude 看不到你 ! 命令的输出，除非你后续手动复制给它。

适合场景：

• 临时查个目录、查个 git 状态
• 不想让 Claude 看到的敏感命令（比如查 secret）
• 不想消耗 token 的简单操作

方式三：让 Claude 用后台模式执行

让 Claude 直接把长跑命令丢到后台：

> 把 dev server 跑起来，在后台
[Claude 用 Bash 工具的 run_in_background 模式启动]
[bash_id: bg-1 已启动]
> 接下来你可以继续对话，server 在后台跑

Claude 能感知到这个后台进程的存在，可以随时让它读 stdout、判断状态、最后 kill 掉。这是最 Claude Code 原生的做法。

---

Bash 工具的后台模式（run_in_background）

这是 Claude Code 的核心特性之一。具体工作机制：

1. 启动命令时设置 run_in_background: true
2. Claude Code 会立刻返回，不等命令结束
3. 返回一个 bash_id（类似 bg-1、bg-2）作为这个后台任务的句柄
4. 后续可以通过 BashOutput / KillShell 等工具按 bash_id 操作

适合后台跑的命令

命令	为什么后台
npm run dev	永远跑，按 Ctrl+C 才停
npm run watch	文件改动时自动重跑
cargo watch -x run	Rust 的热重载
python -m http.server 8000	起一个静态服务器
tail -f logs/app.log	跟踪日志
docker compose up	起一组容器
make watch	长跑构建

不适合后台的命令

命令	为什么前台
git status	秒回，前台直接拿结果方便
npm test	跑完就退，前台等结果
ls, cat, grep	输出本身就是要看的
npm install（短）	等结束了才能继续做下一步

但 npm install 跑 5 分钟时也可以丢后台，等 Claude 让它读输出判断完成。

---

实战：dev server 边跑边对话

场景 1：起 server，改代码，自动重载

> 启动 dev server，后台跑
[Claude 启动后台任务 bg-1: npm run dev]
[输出预览：server started on http://localhost:3000]

> 现在帮我改 src/components/Header.tsx，把 logo 换成新的
[Claude 编辑文件]
[dev server 自动检测到改动并重新加载]

> 看下 server 现在有没有报错
[Claude 调用 BashOutput(bash_id="bg-1") 读最新 stdout]
[显示：Compiled successfully in 1.2s]
> 编译通过了，浏览器刷新看看效果

> 可以了，把 server 停掉吧
[Claude 调用 KillShell(bash_id="bg-1")]
> 已停止

场景 2：测试边跑边讨论失败原因

> 跑一下完整的测试套件，后台跑
[Claude 启动 bg-2: npm test]

> 在等的时候，先帮我看下 src/utils/parser.ts 有没有什么问题
[Claude 一边等测试，一边读代码分析]

> 测试好了吗
[Claude 调用 BashOutput(bash_id="bg-2")]
[显示：30 tests passed, 2 failed]
> 有 2 个失败，是 parser.test.ts 里的两个 case，
> 看起来跟我刚才提到的 parser 问题相关

场景 3：日志监控 + 实时分析

> 后台跟踪 logs/app.log
[Claude 启动 bg-3: tail -f logs/app.log]

> 我现在去触发一下那个会出错的请求
[在另一个终端发请求]

> 日志里有什么错误？
[Claude 读 bg-3 输出，找 ERROR / Exception 关键字]
[发现：NullPointerException at line 42]
> 是 parser 那行的空指针，我帮你修

---

监控后台输出：BashOutput 工具

后台任务跑着，你想知道它现在到哪一步了？让 Claude 读取最新 stdout：

> bg-1 现在输出到哪了
[Claude 用 BashOutput 读取 bg-1 的 stdout 增量]
[只返回上次读取后的新内容，不重复]

BashOutput 的几个特点

• 增量读取：每次只返回上次读完之后的新输出
• 不阻塞：立刻返回当前已经累积的内容，不等新输出
• stderr 也读：默认混合 stdout 和 stderr 一起
• 可以用 grep 过滤：参数里可以传一个 regex，只返回匹配的行

实用模式：等待某个状态

> 启动 docker compose 后台跑
[bg-4 启动]

> 一直等到看到 "ready to accept connections" 才告诉我
[Claude 循环：BashOutput(filter="ready"), 没找到就等几秒再读]
[终于看到这行后]
> 数据库已就绪，可以开始连接了

Monitor 工具：等到某个事件

某些版本的 Claude Code 有 Monitor 工具，可以”挂在那里等到某个 stdout 行出现”：

Monitor(bash_id="bg-4", until_line_matches="ready to accept")
# 阻塞直到匹配，避免来回轮询

如果你的版本没有 Monitor，BashOutput + 重试逻辑也能达到类似效果。

---

自己控制后台进程：& 和 nohup

不通过 Claude，自己直接在 shell 里管理后台进程：

# Claude 对话里
> !npm run dev > /tmp/dev.log 2>&1 &
[1] 12345
# server 在后台跑，pid 12345，日志到 /tmp/dev.log
> # Claude 看不到这个进程，但你可以自己管

# 看进程
> !jobs
[1]+  Running   npm run dev > /tmp/dev.log 2>&1 &

# 把日志拉到对话里给 Claude 看
> 看下 /tmp/dev.log 最近的 50 行有什么错
[Claude 用 Read 或 Bash 读 /tmp/dev.log]

# 停止
> !kill %1
# 或者
> !kill 12345

& vs nohup vs disown

# 1. & 后台跑，但是关闭 shell 时进程会被 SIGHUP 杀掉
npm run dev &

# 2. nohup 忽略 SIGHUP，关 shell 也不会被杀
nohup npm run dev > dev.log 2>&1 &

# 3. disown 把进程从 shell 的 job 列表里摘除
npm run dev &
disown %1

# 推荐：长跑后台进程用 nohup + 日志重定向

检查后台进程

# 列出当前 shell 的 jobs
> !jobs

# 列出所有 node 进程
> !ps aux | grep node

# 找占用 3000 端口的进程
> !lsof -i :3000
# 或在 Windows：
> !netstat -ano | findstr :3000

---

tmux 配合：终极后台方案

复杂场景下，最稳妥的还是 tmux。Claude 在一个 pane 里跑，dev server / 日志 / 测试在别的 pane 里跑。

# 先创建 tmux session
tmux new -s dev

# 切成 4 个 pane
[Prefix + %]   # 垂直切
[Prefix + "]   # 水平切
[Prefix + Tab] # 在 pane 之间切

# Pane 1: Claude
$ claude

# Pane 2: dev server
$ npm run dev

# Pane 3: 日志
$ tail -f logs/app.log

# Pane 4: 临时跑命令
$ git status

Claude 读其他 tmux pane 的输出

让 Claude 看 pane 2 的 dev server 输出：

> 把 tmux pane 2 的最后 30 行内容拿过来，看下 dev server 有没有报错
[Claude 调用 Bash: tmux capture-pane -t :0.1 -p | tail -n 30]
[输出回到对话]

tmux capture-pane -p 是把 pane 内容当 stdout 输出。-t :0.1 表示 session 第 0 个 window 的第 1 个 pane。

和 Claude Code 协作的 tmux 工作流

# 在 tmux 里，让 Claude 直接控制别的 pane
> 在 pane 2 跑 npm run dev
[Claude: !tmux send-keys -t :0.1 'npm run dev' Enter]
> 已发送

> 等 server 起来后帮我跑 e2e 测试在 pane 3
[Claude 监控 pane 2 的输出，看到 "ready" 后]
[Claude: !tmux send-keys -t :0.2 'npm run e2e' Enter]

这种用法把 Claude 变成了一个”指挥官”，多个 pane 是它的工兵。

---

实战脚本：一键起开发环境

写一个脚本统一管理后台进程：

#!/bin/bash
# dev-env.sh

PIDFILE_DIR=/tmp/myproj-pids
mkdir -p "$PIDFILE_DIR"

start() {
  echo "Starting dev server..."
  nohup npm run dev > /tmp/myproj-dev.log 2>&1 &
  echo $! > "$PIDFILE_DIR/dev.pid"

  echo "Starting API mock..."
  nohup npm run mock > /tmp/myproj-mock.log 2>&1 &
  echo $! > "$PIDFILE_DIR/mock.pid"

  echo "All services started. Logs in /tmp/myproj-*.log"
}

stop() {
  for pidfile in "$PIDFILE_DIR"/*.pid; do
    [ -f "$pidfile" ] || continue
    pid=$(cat "$pidfile")
    kill "$pid" 2>/dev/null && echo "Killed $(basename $pidfile .pid) ($pid)"
    rm "$pidfile"
  done
}

status() {
  for pidfile in "$PIDFILE_DIR"/*.pid; do
    [ -f "$pidfile" ] || continue
    pid=$(cat "$pidfile")
    name=$(basename "$pidfile" .pid)
    if kill -0 "$pid" 2>/dev/null; then
      echo "$name: running ($pid)"
    else
      echo "$name: dead"
    fi
  done
}

case "$1" in
  start)  start ;;
  stop)   stop ;;
  status) status ;;
  *) echo "Usage: $0 {start|stop|status}" ;;
esac

然后在 Claude 里：

> !./dev-env.sh start
> !./dev-env.sh status
> 看下 /tmp/myproj-dev.log 的最近输出
> !./dev-env.sh stop

---

一边跑测试一边讨论结果

经典场景：测试要 5 分钟跑完，你不想干等。

> 后台启动测试，我们边等边讨论代码
[bg-5 启动 npm test]

> 测试在跑的时候，帮我看下 src/services/auth.ts
[Claude 读文件、分析]
> 这里第 87 行有个潜在的 race condition，
> 如果两个请求同时来，token 可能被覆盖

> 嗯，记下，等测试结果出来一起看

> 测试现在到哪了？
[BashOutput(bg-5)]
> 已完成 23/45 个测试套件，目前没失败

[5 分钟后]

> 测试好了吗
[BashOutput(bg-5)]
> 完成。Result: 共 320 个测试，318 通过，2 失败
> 失败的是 auth.test.ts 里的两个 race condition 用例
> 这刚好印证了我们刚才在 src/services/auth.ts 看到的那个问题

这种工作流的关键：把”等”的时间用来思考其他问题，而不是盯着滚动的日志发呆。

---

常见问题

Q：后台进程退出后 bash_id 还能用吗？

A：进程死了之后 bash_id 会变成 “exited” 状态。你还能读它最后留下的 stdout，但不能往里发命令了。要重启就启个新的 bash_id。

Q：怎么向后台进程发输入？

A：标准输入比较麻烦，因为后台进程通常没接 tty。如果非要交互，要么用 expect，要么用 tmux send-keys，要么改造程序读文件 / 命名管道。简单情况用 mkfifo：

> !mkfifo /tmp/cmd-pipe
[启动后台命令并把 stdin 接到 fifo]
> !your-command < /tmp/cmd-pipe &
[发送命令]
> !echo "some input" > /tmp/cmd-pipe

Q：Claude 启动的后台进程，关掉 Claude 后还在不在？

A：取决于 Claude Code 版本。一般来说退出 Claude Code 时它会清理自己启动的子进程。如果你需要 Claude 退出后进程还活着，用 nohup ... & 自己 detach，不要走 Claude 的 run_in_background。

Q：BashOutput 输出太多了占满了对话上下文。

A：用 filter 参数（regex）只读关键行：

[BashOutput(bash_id="bg-1", filter="ERROR|WARN")]
# 只看错误和警告

或者读 stdout 文件的尾部：

> !tail -n 50 /tmp/dev.log

Q：跨会话保留后台任务？

A：Claude Code session 间不共享 bash_id。要让进程跨 session 存活，用 nohup / tmux / systemd / supervisord 这类工具自己管。

Q：Windows 没有 nohup 怎么办？

A：Windows 的等价做法：

# PowerShell
Start-Process -NoNewWindow -RedirectStandardOutput dev.log npm "run dev"

# 或用 Start-Job
Start-Job -ScriptBlock { npm run dev } -Name dev

# 列出
Get-Job

# 停止
Stop-Job -Name dev

或者直接用 WSL2 + Linux 习惯。

---

快速参考

直接 shell 命令      ! 前缀（Claude 看不到输出）
让 Claude 跑命令     直接说，前台默认
让 Claude 后台跑     说"后台跑" / "并发跑"
读后台输出           BashOutput(bash_id)
等到某状态           Monitor(...) 或 BashOutput 重试
停止后台             KillShell(bash_id)

自己后台进程         cmd > log 2>&1 &
关 shell 也不死      nohup cmd > log 2>&1 &
查所有 jobs          jobs
按 pid 停            kill <pid>
按 job 号停          kill %1

tmux 协作           tmux capture-pane -t :0.1 -p
                    tmux send-keys -t :0.1 'cmd' Enter