cc-connect 接入 Discord：安装、配置与稳定运行记录

我这次折腾 cc-connect，目标很明确：把本机的 Codex CLI 接到 Discord，让读代码、改文件、执行命令这些动作，可以直接在聊天窗口里完成。

装完以后我最大的感受是：这类工具真正值得整理的，不只是“怎么安装”，而是“怎么配置以后才会顺手”。所以这篇文章重点记录 4 件事：安装方式、Discord 侧配置、后台运行方式，以及最后保留下来的使用习惯。

先说结论

我最后留下来的组合是这样的：

• Codex CLI 负责真正执行任务
• cc-connect@beta 负责桥接 Discord
• guild_id 用来做服务器级 slash command 注册
• group_reply_all = true 让固定频道更像操作台
• quiet = true 保持频道干净
• tmux 负责让服务常驻运行

对我来说，这套组合的重点不是“功能最多”，而是日常用起来阻力最小。

1. 我最后采用的安装方式

如果你准备走 Codex + Discord 这条路线，我建议一开始就把版本选对：

npm install -g @openai/codex
npm install -g --prefix "$HOME/.npm-global" cc-connect@beta

codex --version
$HOME/.npm-global/bin/cc-connect --version

我最后直接用了 cc-connect@beta，因为如果希望在 Discord 里正常使用 /new、/status、/help 这些 slash commands，beta 版本会省掉很多来回折腾的时间。

这类桥接工具的关键不是“能不能启动”，而是“命令交互是不是顺畅”。只要这一层顺了，后面的体验就会稳定很多。

2. Discord 侧我重点确认了什么

在 Discord Developer Portal 里，我最后确认了下面这些基础项：

1. 创建应用并添加 Bot
2. 开启 Message Content Intent
3. 在 OAuth2 URL Generator 里勾选：
   • bot
   • applications.commands
4. 给机器人至少这些权限：
   • View Channels
   • Send Messages
   • Read Message History
   • Send Messages in Threads
   • Use Slash Commands

这些步骤看起来普通，但它们其实决定了后面绝大多数交互体验。基础权限没配齐，客户端里的现象就会很绕；只要这里对齐了，后面的流程基本就清晰了。

3. 我保留下来的 config.toml

这是我最后保留的一份思路比较清楚的配置，内容做了脱敏：

language = "zh"

[log]
level = "info"

[[projects]]
name = "default"
quiet = true

[projects.agent]
type = "codex"

[projects.agent.options]
work_dir = "/absolute/path/to/your/project"
mode = "suggest"

[[projects.platforms]]
type = "discord"

[projects.platforms.options]
token = "YOUR_DISCORD_BOT_TOKEN"
allow_from = "YOUR_DISCORD_USER_ID"
guild_id = "YOUR_GUILD_ID"
group_reply_all = true

我比较在意的是这几项：

• guild_id：让 slash commands 走服务器级注册，命令出现更快
• allow_from：只保留自己的账号，边界更清楚
• group_reply_all = true：在固定频道里使用时，不用每次都 @ 机器人
• quiet = true：不把思考过程和工具进度反复刷到聊天窗口

这些配置本身不复杂，但它们会直接决定你最后得到的是“能用”，还是“顺手”。

4. 我是怎么把它跑稳定的

安装完成后，我没有把 cc-connect 当成一次性命令，而是把它当成一个需要常驻的本地服务。

我最后采用的是 tmux：

tmux new-session -d -s cc-connect \
  '$HOME/.npm-global/bin/cc-connect -config $HOME/.cc-connect/config.toml >> $HOME/.cc-connect/cc-connect.log 2>&1'

配合下面两个命令，基本就够日常维护了：

tmux ls
tail -f ~/.cc-connect/cc-connect.log

我喜欢这种方式，主要是因为它足够直接：

• 启停明确
• 日志集中
• 断开当前终端后也不影响服务继续跑
• 出现异常时可以先看日志，而不是只盯着 Discord 客户端猜

如果后面要长期使用，我会更倾向于把它当成本地常驻组件，而不是“需要时临时启动一下”的工具。

5. 我最后保留下来的使用习惯

真正跑顺以后，我的使用方式也慢慢固定下来了：

• 把 Discord 里的某个频道当作固定操作台
• 平时主要通过 slash commands 管理会话
• 普通消息直接作为后续输入，不再频繁切回终端
• 通过 quiet = true 保持频道只看结果，不看过程
• 通过 group_reply_all = true 降低交互摩擦

说到底，这并不是在“多装一个机器人”，而是在把本地工作流往聊天界面里延伸。

6. 这次整理下来，我最在意的经验

如果以后我重新搭一遍，我还是会优先做下面几件事：

• 一开始就把 Discord 基础权限配完整
• 一开始就写 guild_id，不要等命令慢慢同步
• 一开始就决定消息触发方式，要不要默认群聊直接回复
• 一开始就把日志放到固定位置，方便快速判断问题
• 一开始就用稳定的常驻运行方式，而不是临时后台命令

对我来说，这次最大的收获不是“终于把机器人接进去了”，而是把这条链路真正理顺了：

当本地 agent、聊天平台、命令注册和后台运行方式对齐之后，cc-connect 才会从一个“可以试试的工具”，变成真正能进入日常工作流的东西。

这也是我最后愿意把它写进博客的原因。它不只是一个安装记录，更像一次把工作方式重新整理清楚的过程。