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` 这条路线，我建议一开始就把版本选对：

1npm install -g @openai/codex
2npm install -g --prefix "$HOME/.npm-global" cc-connect@beta
3
4codex --version
5$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`

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

1language = "zh"
2
3[log]
4level = "info"
5
6[[projects]]
7name = "default"
8quiet = true
9
10[projects.agent]
11type = "codex"
12
13[projects.agent.options]
14work_dir = "/absolute/path/to/your/project"
15mode = "suggest"
16
17[[projects.platforms]]
18type = "discord"
19
20[projects.platforms.options]
21token = "YOUR_DISCORD_BOT_TOKEN"
22allow_from = "YOUR_DISCORD_USER_ID"
23guild_id = "YOUR_GUILD_ID"
24group_reply_all = true

我比较在意的是这几项：

• `guild_id`：让 slash commands 走服务器级注册，命令出现更快

• `allow_from`：只保留自己的账号，边界更清楚

• `group_reply_all = true`：在固定频道里使用时，不用每次都 `@` 机器人

• `quiet = true`：不把思考过程和工具进度反复刷到聊天窗口

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

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

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

我最后采用的是 `tmux`：

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

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

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

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

• 启停明确

• 日志集中

• 断开当前终端后也不影响服务继续跑

• 出现异常时可以先看日志，而不是只盯着 Discord 客户端猜

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

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

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

• 把 Discord 里的某个频道当作固定操作台

• 平时主要通过 slash commands 管理会话

• 普通消息直接作为后续输入，不再频繁切回终端

• 通过 `quiet = true` 保持频道只看结果，不看过程

• 通过 `group_reply_all = true` 降低交互摩擦

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

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

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

• 一开始就把 Discord 基础权限配完整

• 一开始就写 `guild_id`，不要等命令慢慢同步

• 一开始就决定消息触发方式，要不要默认群聊直接回复

• 一开始就把日志放到固定位置，方便快速判断问题

• 一开始就用稳定的常驻运行方式，而不是临时后台命令

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

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

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