1. 先把链路想清楚：Telegram 只是遥控器，Codex 才是干活的那台机器
在 Windows 上折腾 cc-connect 之前，我建议你先在脑子里画一张图，不然很容易把「Bot 连上了」误判成「整套跑通了」。这套东西的本质链路是这样的：
Telegram Bot -> cc-connect 本机进程 -> Codex CLI -> 你配置的本地项目目录
也就是说，Telegram 只是一个远程遥控器，真正读文件、改代码的是你 Windows 机器上的 Codex CLI。cc-connect 是夹在中间的本机桥接程序，它负责把 Telegram 的消息翻译成对 Codex 的调用，再把结果回传。
这个定位决定了三件事。第一，电脑关机、睡眠、断网，或者 cc-connect 进程没在跑，Bot 都不会有任何反应，这不是 bug，是架构决定的。第二，Telegram 客户端能连上，不代表 cc-connect 能连上 Telegram Bot API，两者走的通道可能完全不同。第三，Codex 能不能被正确调起，取决于 Windows 的命令查找顺序，这里有个非常典型的坑，后面会专门讲。
适合谁看：已经在 Windows 上装好 Node.js 和 Codex CLI、想让手机随时指挥本机 Codex 处理项目的人。如果你还没装 Codex CLI，先把那一步做完再回来。整篇我会给你可复制的 config.toml、启动脚本、验证命令，以及一份排查清单，目标是让你从零跑通，并且知道每一步为什么这么配。
2. 前置准备：TaoToken 统一 Key 与 Codex CLI 的接入
在讲 cc-connect 之前，得先把 Codex CLI 这一端的「大脑」接好。Codex CLI 需要一个可用的模型 API 通道，这里我用 TaoToken 做统一入口，好处是 Key 和通道集中管理，后面 cc-connect 调 Codex 时不用再关心底层走哪家。
TaoToken 官网入口：https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=
API 地址（配置里填这个）：https://taotoken.net/api
你需要先在控制台创建一个 API Key，然后把它配置到 Codex CLI 的环境变量或配置文件里。Codex CLI 通常读取OPENAI_API_KEY和OPENAI_BASE_URL这类变量，具体字段名以你装的版本为准。核心思路是：把 base_url 指向 TaoToken 的 API 地址，把 key 换成你在 TaoToken 生成的 Key。
创建 Key 的入口在这里：
- API Keys 管理：https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite
- 接入文档：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite
注意：Key 只存在你本机的环境变量或配置文件里，不要写进会提交到 Git 的文件，也不要在 Telegram 里发给任何人。
配置完之后，先在命令行单独验证 Codex CLI 能跑起来，再去接 cc-connect。这一步很关键，因为如果 Codex 本身没通，你后面在 Telegram 里发消息只会看到一堆超时，排查方向会被带偏。
# 设置当前会话的环境变量（示例，字段名以你的 Codex 版本为准） $env:OPENAI_API_KEY = "你的TaoToken Key" $env:OPENAI_BASE_URL = "https://taotoken.net/api" # 验证 Codex CLI 能正常响应 codex --version如果codex --version能打印版本，说明 CLI 本体没问题。接下来再让它实际跑一次对话或分析，确认 API 通道是通的。只有这一步稳了，cc-connect 才有意义。
3. 安装 cc-connect 并写出可复制的 config.toml
Windows 上装 cc-connect，第一原则是优先用npm.cmd，别用npm。原因是 PowerShell 默认的执行策略会拦截.ps1脚本，你直接敲npm install很可能报「无法加载文件 npm.ps1，因为在此系统上禁止运行脚本」。这不是 cc-connect 的问题，是 PowerShell 的策略问题，改系统策略属于下策，直接换.cmd最省事。
npm.cmd install -g cc-connect cc-connect.cmd --version如果cc-connect.cmd --version能输出版本号，安装就成功了。如果还是报.ps1相关错误，说明你调用的还是.ps1包装脚本，改用.cmd或直接调用全局目录里的cc-connect.exe。
配置文件默认放在：
C:\Users\<你的用户名>\.cc-connect\config.toml下面是一份最小可用骨架，你可以直接复制后替换占位内容：
language = "zh" [log] level = "info" [[projects]] name = "my-project" admin_from = "你的Telegram数字ID" [projects.agent] type = "codex" [projects.agent.options] work_dir = "D:/your-project" mode = "suggest" [[projects.platforms]] type = "telegram" [projects.platforms.options] token = "你的Telegram Bot Token" allow_from = "你的Telegram数字ID"几个字段解释一下。work_dir是 Codex 实际操作的目录，所有文件读写都发生在这里，建议先用一个测试项目，别一上来就指向重要仓库。mode = "suggest"表示先给建议、不直接改文件，跑通后再考虑放开。admin_from和allow_from是权限控制，第一次不知道自己的 Telegram 数字 ID 时，可以临时写"*"，但跑通后必须立刻改成真实数字 ID。
Telegram Bot Token 通过 @BotFather 创建 bot 获取。这个 token 等同于你 bot 的控制权，不要发到任何公开渠道，也不要贴进聊天记录。
4. 拿到 Telegram 数字 ID 并锁定权限
很多人卡在这里：以为 Telegram 的用户名或昵称就是 ID，其实不是。cc-connect 需要的是纯数字 ID。最省事的办法是先让 bot 跑起来，然后在 Telegram 里给它发：
/whoami如果配置里allow_from还是"*"，这条命令应该能返回你的数字 ID。另一种方式是看 cc-connect 的日志，里面会打印 session 和 user 信息，从中也能找到数字 ID。
拿到之后，把配置改成：
admin_from = "123456789" allow_from = "123456789"这一步别偷懒。allow_from = "*"意味着任何知道你 bot 的人都能给你的本机 Codex 发指令，等于把本地项目目录的操作权开放出去了。跑通验证阶段临时用一下可以，验证完立刻收紧。
5. Windows 上最容易踩的 Codex 坑：WindowsApps 别名劫持
这是本篇最值得单独拎出来讲的一个坑，也是很多人「Telegram 连上了但 Codex 死活起不来」的根因。
现象是这样的，cc-connect 日志里出现类似：
fork/exec C:\Program Files\WindowsApps\...\codex.exe: Access is denied.原因是 cc-connect 固定调用codex这个命令名，而 Windows 的命令查找顺序会先命中C:\Program Files\WindowsApps\下的 App Alias。这个路径对普通进程来说不能直接 fork/exec，于是就 Access denied 了。
先诊断，看命令到底解析到哪：
where.exe codex Get-Command codex -All如果where.exe codex第一行就是C:\Program Files\WindowsApps\...，那基本可以确认是这个坑。
可行的解决思路是：找到真实的 Codex CLI 路径，复制一份到普通目录，然后在启动 cc-connect 前把这个目录放到 PATH 最前面。真实路径通常长这样：
C:\Users\<你的用户名>\AppData\Local\OpenAI\Codex\bin\codex.exe复制到普通目录：
mkdir C:\cc-connect-bin copy "C:\Users\<你的用户名>\AppData\Local\OpenAI\Codex\bin\codex.exe" C:\cc-connect-bin\codex.exe然后用启动脚本把C:\cc-connect-bin放到 PATH 最前。这里要提醒一句：不要盲目去配cli_path。不同版本的 cc-connect 对 Codex 的配置字段支持不一致，某些稳定版根本不认cli_path，你写了也会被忽略。遇到cli_path不生效，优先用 PATH 方案解决命令查找问题，这是最稳的。
6. 启动脚本与验证：看到哪些日志才算真跑通
建议写一个.bat启动脚本，把 PATH 和配置路径都固定下来，避免每次手动设环境变量。
@echo off setlocal set "PATH=C:\cc-connect-bin;%PATH%" set "CC_CONNECT_EXE=%APPDATA%\npm\node_modules\cc-connect\bin\cc-connect.exe" set "CC_CONNECT_CONFIG=%USERPROFILE%\.cc-connect\config.toml" "%CC_CONNECT_EXE%" --config "%CC_CONNECT_CONFIG%" --force双击即可启动。启动前再确认一次命令解析顺序：
where.exe codex第一项应该是C:\cc-connect-bin\codex.exe，而不是 WindowsApps 路径。
进程检查与停止：
Get-Process cc-connect Stop-Process -Name cc-connect接下来是验证环节，这里要分清两个层次，很多人就是在这里误判的。
第一层，Telegram 平台连接成功，日志里会出现：
telegram: connected platform ready telegram: registered bot commands第二层，Codex 真正跑通，给 bot 发一条普通消息后，日志里会出现：
message received session spawned turn complete注意：只看到
telegram: connected只能说明 bot 连上了 Telegram，不代表 Codex 能被调起。必须看到session spawned和turn complete，才算整条链路通了。
Telegram 里常用命令也记一下：/new新开会话，/status查看状态，/whoami获取数字 ID，/sessions查看会话列表。
7. 本篇常见报错排查清单
把上面这些坑整理成一张对照表，出问题时按顺序查：
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| npm.ps1 无法加载 | PowerShell 执行策略拦截 | 改用 npm.cmd / cc-connect.cmd |
| Telegram 客户端能连，Bot 无响应 | Bot API 通道不通 | 用 curl.exe -I https://api.telegram.org 诊断 |
| fork/exec WindowsApps Access denied | 命令被 App Alias 劫持 | 复制真实 codex.exe 到普通目录并前置 PATH |
| cli_path 配了不生效 | 版本不支持该字段 | 放弃 cli_path，改用 PATH 方案 |
| 只有 telegram: connected | Codex 未真正启动 | 检查 where.exe codex 与 Codex 自身可用性 |
| 改了 allow_from 仍被陌生人触发 | 配置未重载 | 重启 cc-connect 进程 |
| 关机后 Bot 不工作 | 本机服务未运行 | 属正常现象，保持机器与进程在线 |
再补几条经验。不要把 Telegram 客户端能连等同于 Bot API 能连，客户端可能走内置通道，而 cc-connect 访问的是https://api.telegram.org，用curl.exe -I https://api.telegram.org单独验证。修改文件只会发生在work_dir下，先用suggest模式观察行为，别一上来就开高权限模式。cc-connect 是本机服务，电脑关机后 bot 不会工作，这是设计如此。
如果你在 Codex 调用链路上还想单独验证模型响应，可以直接用模型对话页面测一下通道是否正常：
- 模型对话：https://taotoken.net/model-chat?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite
8. 让 AI 帮你跑通时，把这段提示词丢给它
如果你想让 AI 按步骤协助你配置，可以把下面这段直接发过去，把占位内容替换成你自己的：
请帮我在 Windows 上配置 cc-connect，把 Telegram Bot 接入本机 Codex CLI。 要求： 1. 用 npm.cmd 安装 cc-connect，避免 PowerShell .ps1 执行策略问题。 2. 配置文件写到 %USERPROFILE%\.cc-connect\config.toml。 3. Telegram token 用我提供的 token，但不要在输出中复述。 4. 项目目录是：<替换为你的项目目录>。 5. 优先使用 Codex agent，mode 先用 suggest。 6. 启动后检查日志是否出现 telegram: connected、platform ready。 7. 如果 Codex 报 WindowsApps Access denied，请检查 where.exe codex 和 Get-Command codex -All。 8. 如 WindowsApps 抢占 codex，请把真实 codex.exe 复制到普通目录，并用启动脚本把该目录放到 PATH 最前。 9. 跑通后让我发送 /whoami，再把 allow_from 和 admin_from 锁定为我的 Telegram 数字 ID。 10. 每一步都要验证，不要只看安装成功就判断跑通。最后说一个我自己的习惯：每次改完配置，先重启 cc-connect，再发一条/status，然后发一条普通消息看日志有没有turn complete。三步都过，才算这次改动是安全的。长期在 Windows 上跑这套链路、还要接更多 Agent 场景的话，可以顺手看下 Coding Plan，把 Key 和额度统一管理起来会省很多事：
- Coding Plan：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite
- 控制台：https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite
把 PATH 顺序、allow_from 锁定、日志三层验证这三件事做扎实，Windows 上这套 Telegram + Codex 的链路基本就不会再反复翻车了。
