尧图网站建设 
1. 多 Docker 里 Codex 的 MCP 和 Skills 为什么总有一个不生效如果你在多个 Docker 容器或多台机器上共用同一个 workspace 目录大概率会遇到这个场景Skills 明明放在共享目录里Codex 能识别但 MCP 面板里翻来覆去只显示一个codex_apps之前配好的 context7、sequential-thinking、chrome-devtools 全都不见了。更让人头疼的是有时候 Codex 直接报failed to load configuration: duplicate key连启动都启动不了。这个问题的核心在于Codex 对 Skills 和 MCP 的发现机制完全不同。Skills 走的是用户级目录扫描只要~/.agents/skills或项目.agents/skills下有SKILL.md基本都能被识别而 MCP 强依赖config.toml的加载路径和 trust 状态项目级配置如果没被正确加载MCP server 就不会出现在面板里。再加上多个容器各自维护~/.codex/config.toml反复用cat 追加配置很容易出现同名 TOML table 重复定义直接导致整个配置文件加载失败。这篇内容面向正在用 Codex Docker 做多环境开发的用户目标是把 MCP 和 Skills 的跨容器共享方案讲清楚给出一份可以直接复制的config.toml骨架配合 Docker 挂载验证步骤让多个容器稳定复用同一套 MCP 与 Skills 配置。同时把 API Key 统一管理的问题一起解决避免每个容器里散落一堆明文 Key。2. 用 TaoToken 统一 Key先把 MCP 的鉴权入口收拢在讲 config.toml 之前先解决一个前置问题MCP server 和 Codex 本身都需要 API Key如果每个 Docker 里都手动配一遍不仅容易漏还会出现 Key 版本不一致的情况。我的做法是用 TaoToken 作为统一的 Key 管理入口所有容器从同一个环境变量读取。TaoToken 的定位是给开发者提供统一的模型调用入口支持模型对话、Coding Plan、API Keys 管理等功能。你可以在官网注册后进入控制台创建 API Key然后在每个 Docker 的共享 bashrc 里统一 export这样所有容器读到的都是同一套 Key。具体操作路径注册并登录官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content进入控制台创建 API Keyhttps://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI Key 管理页https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content需要验证模型是否可用时用模型对话页测试https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content长期编码或 Agent 场景可以看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content接入文档参考https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 端点统一用https://taotoken.net/api拿到 Key 之后不要写进config.toml而是通过环境变量注入。这样做的原因是config.toml会被多个容器共享或挂载明文 Key 写进去等于把凭据暴露在共享目录里而环境变量可以在每个容器启动时独立注入互不干扰。3. 可复制的 config.toml 骨架与 Docker 挂载方案3.1 用户级 config.toml 完整骨架最稳妥的做法是把 MCP server 配置放在用户级~/.codex/config.toml这样不依赖当前打开的是哪个目录。下面这份配置可以直接复制把 Key 相关的部分留空靠环境变量填充model gpt-5.5 model_reasoning_effort high sandbox_mode workspace-write personality pragmatic [plugins.githubopenai-curated] enabled true [projects./workspace] trust_level trusted [projects./root/workspace] trust_level trusted [tui.model_availability_nux] gpt-5.5 1 # # MCP Servers # User-level config: always available in this Docker # [mcp_servers.chrome-devtools] command npx args [-y, chrome-devtools-mcplatest] startup_timeout_sec 30 tool_timeout_sec 120 enabled true [mcp_servers.context7] command npx args [-y, upstash/context7-mcp] env_vars [CONTEXT7_API_KEY] startup_timeout_sec 30 tool_timeout_sec 120 enabled true [mcp_servers.sequential-thinking] command npx args [-y, modelcontextprotocol/server-sequential-thinking] startup_timeout_sec 30 tool_timeout_sec 120 enabled true [mcp_servers.arxiv-mcp-server] command npx args [-y, langgpt/arxiv-mcp-serverlatest] env_vars [SILICONFLOW_API_KEY] startup_timeout_sec 30 tool_timeout_sec 120 enabled true [mcp_servers.arxiv-mcp-server.env] WORK_DIR /workspace/arxiv-mcp-server [mcp_servers.drawio] command npx args [-y, next-ai-drawio/mcp-serverlatest] startup_timeout_sec 30 tool_timeout_sec 120 enabled true这份配置的关键点env_vars声明了需要从环境变量读取的 Key真实值不落盘projects段把/workspace和/root/workspace都标记为 trusted避免因为软链接路径导致 trust 判断失败。3.2 共享 bashrc 统一注入 Key多个 Docker 共用同一个 workspace 时推荐用一个共享 bashrc 文件来统一管理环境变量每个容器的~/.bashrc只负责 source 它cat /workspace/.shared_bashrc EOF # Shared bashrc for all Docker containers export TAOTOKEN_API_KEY你的 TaoToken API Key export CONTEXT7_API_KEY你的 Context7 API Key export SILICONFLOW_API_KEY你的 SiliconFlow API Key export WORKSPACE/workspace export CODEX_WORKSPACE/workspace alias llls -alF alias lals -A alias lls -CF export NPM_CONFIG_CACHE/workspace/.cache/npm export PIP_CACHE_DIR/workspace/.cache/pip mkdir -p /workspace/.cache/npm /workspace/.cache/pip 2/dev/null || true EOF然后在每个容器的~/.bashrc里加一行 source用 grep 判断避免重复追加grep -qxF [ -f /workspace/.shared_bashrc ] source /workspace/.shared_bashrc ~/.bashrc || \ echo [ -f /workspace/.shared_bashrc ] source /workspace/.shared_bashrc ~/.bashrc source ~/.bashrc3.3 Docker 挂载验证步骤假设你的 Docker 启动命令里已经挂载了 workspace验证挂载是否生效可以按下面几步走# 1. 确认 workspace 挂载点 mount | grep workspace # 2. 确认共享 bashrc 可读 ls -l /workspace/.shared_bashrc # 3. 确认环境变量已注入 python3 - PY import os for k in [TAOTOKEN_API_KEY, CONTEXT7_API_KEY, SILICONFLOW_API_KEY]: print(f{k}: {OK if os.environ.get(k) else MISSING}) PY # 4. 确认 config.toml 存在且语法正确 ls -l ~/.codex/config.toml如果第 3 步输出 MISSING说明 bashrc 没被 source检查~/.bashrc里那行 source 语句是否在非交互式 shell 下也能执行。VS Code 的 Codex 插件进程不一定继承.bashrc这种情况需要 Reload Window 或重连 Remote-SSH。4. 验证 MCP 与 Skills 是否真正生效4.1 手动测试 MCP server 能否启动stdio 类型的 MCP 不建议手动长期后台运行Codex 会根据command和args自动拉起。手动运行只用于排错# Context7 timeout 10s npx -y upstash/context7-mcp echo context7 exit$? # Sequential Thinking timeout 10s npx -y modelcontextprotocol/server-sequential-thinking echo sequential-thinking exit$? # arxiv MCP mkdir -p /workspace/arxiv-mcp-server timeout 10s env WORK_DIR/workspace/arxiv-mcp-server SILICONFLOW_API_KEY$SILICONFLOW_API_KEY \ npx -y langgpt/arxiv-mcp-serverlatest echo arxiv exit$? # drawio MCP timeout 10s npx -y next-ai-drawio/mcp-serverlatest echo drawio exit$?如果返回124通常表示该 stdio MCP server 能正常启动只是在等待 MCP client 输入属于正常现象。如果返回其他非零值说明依赖缺失或包名有误。4.2 检查 TOML 语法Python 3.11 以上自带tomllib可以直接校验python3 - PY import os try: import tomllib except ModuleNotFoundError: print(Python 3.11, skip TOML check.) raise SystemExit(0) path os.path.expanduser(~/.codex/config.toml) with open(path, rb) as f: tomllib.load(f) print(config.toml OK) PY输出config.toml OK说明没有 duplicate key 或语法错误。4.3 检查 Skills 是否被扫描到find ~/.agents/skills -maxdepth 3 -name SKILL.md -print如果 Skills 放在共享目录/workspace/.agents/skills需要在每个容器里做软链接mkdir -p ~/.agents rm -rf ~/.agents/skills ln -s /workspace/.agents/skills ~/.agents/skills对于层级较深的子 skills比如ai-infra-skills/.claude/skills/01-server/SKILL.md普通扫描器不一定能发现需要把子 skill 软链接到顶层for d in ~/.agents/skills/ai-infra-skills/.claude/skills/*; do if [ -f $d/SKILL.md ]; then nameai-infra-$(basename $d) ln -sfn $d $HOME/.agents/skills/$name echo linked: $HOME/.agents/skills/$name - $d fi done4.4 Reload Window 是必须步骤修改 MCP 配置或环境变量后旧 Codex 会话不会热加载。推荐顺序保存~/.codex/config.tomlsource ~/.bashrcVS Code 执行Developer: Reload Window新建 Codex 会话如果仍不生效执行Remote-SSH: Kill VS Code Server on Host后重连实测下来Reload Window 之后所有 MCP 工具都能恢复显示。5. 本篇常见错误排查5.1 duplicate key 报错报错信息failed to load configuration: /root/.codex/config.toml:15:11: duplicate key原因是多次用cat 追加配置导致同名 TOML table 重复出现[projects./workspace] trust_level trusted [projects./workspace] trust_level trustedTOML 不允许同一个 key 或 table 重复定义。解决方式是备份后重建cp ~/.codex/config.toml ~/.codex/config.toml.bak.$(date %Y%m%d_%H%M%S) 2/dev/null || true然后手动编辑删除重复的 table。添加新 MCP 前先 grep 检查grep -n ^\[mcp_servers\.context7\] ~/.codex/config.toml grep -n ^\[mcp_servers\.sequential-thinking\] ~/.codex/config.toml grep -n ^\[projects\./workspace\] ~/.codex/config.toml5.2 MCP 面板只显示 codex_apps这个现象说明 Codex 当前只加载了用户级~/.codex/config.toml没有加载项目级/workspace/.codex/config.toml里的 MCP server。常见原因VS Code 当前打开的根目录不是/workspace而是某个子目录Codex 会话是在 MCP 配置修改前创建的旧会话没有热加载项目级配置没有被 trustVS Code Codex 插件没有 Reload Windowconfig.toml有 duplicate key导致整个配置加载失败最稳的解决方式是把 MCP server 写入用户级~/.codex/config.toml不依赖项目级配置。5.3 /root/workspace 与 /workspace 路径不一致检查结果pwd -P # /workspace/.codex readlink -f /workspace # /workspace readlink -f /root/workspace # /workspace说明/root/workspace是/workspace的软链接实际指向同一目录。所以 MCP 不显示的根因不是路径不一致而是项目级配置没被加载。5.4 npx 依赖缺失很多 MCP 用 npx 启动每个 Docker 内部都需要检查node -v npm -v npx -v python3 --version如果缺失apt update apt install -y nodejs npm5.5 环境变量在插件进程里读不到.bashrc新增环境变量后VS Code Codex 插件进程不一定立刻继承。需要 Reload Window 或重连 Remote-SSH。如果还是不行检查~/.bashrc里的 source 语句是否在非交互式 shell 下也会执行必要时把 export 语句放到/etc/profile.d/下。6. 后续规范与统一接入建议把 MCP 和 Skills 的长期维护规范固定下来能省掉大量重复排查时间。MCP 规范MCP server 优先写入用户级~/.codex/config.toml共享项目级/workspace/.codex/config.toml可以保留但不要依赖它作为唯一来源不要反复cat 追加同名 table添加前先 grep 检查是否存在API Key 用env_vars不直接写入config.toml修改后必须 Reload WindowSkills 规范每个 skill 必须有SKILL.md可共享的 skills 放/workspace/.agents/skills每个 Docker 用软链接把~/.agents/skills指向共享目录深层子 skills 用软链接暴露到顶层修改或新增后 Reload Window 或新建 Codex 会话多 Docker 共享结构/workspace/ ├── .codex/config.toml # 可选项目级 MCP 配置 ├── .agents/skills/ # 共享 skills ├── AGENTS.md # 项目级 Codex 使用规则 ├── .shared_bashrc # 共享环境变量和 alias └── arxiv-mcp-server/ # arxiv MCP 工作目录每个 Docker 独立维护~/.codex/config.toml中的最终 MCP 配置、Codex 登录状态、API Key 环境变量、node/npm/python 依赖。Key 统一管理这块用 TaoToken 的 API Keys 页面创建 Key 后通过共享 bashrc 注入到所有容器避免每个容器单独配置。需要验证模型连通性时用模型对话页快速测试长期编码或 Agent 场景可以看 Coding Plan 的额度方案。接入细节参考接入文档API 端点统一用https://taotoken.net/api。最后提醒一个容易忽略的点如果想让所有 Docker 共用 bashrc不建议直接把~/.bashrc软链接为同一个文件因为不同容器可能有自己的 conda、CUDA、PATH 配置。推荐每个容器保留自己的~/.bashrc只 source 共享文件/workspace/.shared_bashrc这样既能统一 Key又不会破坏各容器的独立环境。 Codex MCP 与 Skills 跨 Docker 共享问题总结与后续规范：TaoToken 统一 Key 配置实践
1. 多 Docker 里 Codex 的 MCP 和 Skills 为什么总有一个不生效如果你在多个 Docker 容器或多台机器上共用同一个 workspace 目录大概率会遇到这个场景Skills 明明放在共享目录里Codex 能识别但 MCP 面板里翻来覆去只显示一个codex_apps之前配好的 context7、sequential-thinking、chrome-devtools 全都不见了。更让人头疼的是有时候 Codex 直接报failed to load configuration: duplicate key连启动都启动不了。这个问题的核心在于Codex 对 Skills 和 MCP 的发现机制完全不同。Skills 走的是用户级目录扫描只要~/.agents/skills或项目.agents/skills下有SKILL.md基本都能被识别而 MCP 强依赖config.toml的加载路径和 trust 状态项目级配置如果没被正确加载MCP server 就不会出现在面板里。再加上多个容器各自维护~/.codex/config.toml反复用cat 追加配置很容易出现同名 TOML table 重复定义直接导致整个配置文件加载失败。这篇内容面向正在用 Codex Docker 做多环境开发的用户目标是把 MCP 和 Skills 的跨容器共享方案讲清楚给出一份可以直接复制的config.toml骨架配合 Docker 挂载验证步骤让多个容器稳定复用同一套 MCP 与 Skills 配置。同时把 API Key 统一管理的问题一起解决避免每个容器里散落一堆明文 Key。2. 用 TaoToken 统一 Key先把 MCP 的鉴权入口收拢在讲 config.toml 之前先解决一个前置问题MCP server 和 Codex 本身都需要 API Key如果每个 Docker 里都手动配一遍不仅容易漏还会出现 Key 版本不一致的情况。我的做法是用 TaoToken 作为统一的 Key 管理入口所有容器从同一个环境变量读取。TaoToken 的定位是给开发者提供统一的模型调用入口支持模型对话、Coding Plan、API Keys 管理等功能。你可以在官网注册后进入控制台创建 API Key然后在每个 Docker 的共享 bashrc 里统一 export这样所有容器读到的都是同一套 Key。具体操作路径注册并登录官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content进入控制台创建 API Keyhttps://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI Key 管理页https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content需要验证模型是否可用时用模型对话页测试https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content长期编码或 Agent 场景可以看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content接入文档参考https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 端点统一用https://taotoken.net/api拿到 Key 之后不要写进config.toml而是通过环境变量注入。这样做的原因是config.toml会被多个容器共享或挂载明文 Key 写进去等于把凭据暴露在共享目录里而环境变量可以在每个容器启动时独立注入互不干扰。3. 可复制的 config.toml 骨架与 Docker 挂载方案3.1 用户级 config.toml 完整骨架最稳妥的做法是把 MCP server 配置放在用户级~/.codex/config.toml这样不依赖当前打开的是哪个目录。下面这份配置可以直接复制把 Key 相关的部分留空靠环境变量填充model gpt-5.5 model_reasoning_effort high sandbox_mode workspace-write personality pragmatic [plugins.githubopenai-curated] enabled true [projects./workspace] trust_level trusted [projects./root/workspace] trust_level trusted [tui.model_availability_nux] gpt-5.5 1 # # MCP Servers # User-level config: always available in this Docker # [mcp_servers.chrome-devtools] command npx args [-y, chrome-devtools-mcplatest] startup_timeout_sec 30 tool_timeout_sec 120 enabled true [mcp_servers.context7] command npx args [-y, upstash/context7-mcp] env_vars [CONTEXT7_API_KEY] startup_timeout_sec 30 tool_timeout_sec 120 enabled true [mcp_servers.sequential-thinking] command npx args [-y, modelcontextprotocol/server-sequential-thinking] startup_timeout_sec 30 tool_timeout_sec 120 enabled true [mcp_servers.arxiv-mcp-server] command npx args [-y, langgpt/arxiv-mcp-serverlatest] env_vars [SILICONFLOW_API_KEY] startup_timeout_sec 30 tool_timeout_sec 120 enabled true [mcp_servers.arxiv-mcp-server.env] WORK_DIR /workspace/arxiv-mcp-server [mcp_servers.drawio] command npx args [-y, next-ai-drawio/mcp-serverlatest] startup_timeout_sec 30 tool_timeout_sec 120 enabled true这份配置的关键点env_vars声明了需要从环境变量读取的 Key真实值不落盘projects段把/workspace和/root/workspace都标记为 trusted避免因为软链接路径导致 trust 判断失败。3.2 共享 bashrc 统一注入 Key多个 Docker 共用同一个 workspace 时推荐用一个共享 bashrc 文件来统一管理环境变量每个容器的~/.bashrc只负责 source 它cat /workspace/.shared_bashrc EOF # Shared bashrc for all Docker containers export TAOTOKEN_API_KEY你的 TaoToken API Key export CONTEXT7_API_KEY你的 Context7 API Key export SILICONFLOW_API_KEY你的 SiliconFlow API Key export WORKSPACE/workspace export CODEX_WORKSPACE/workspace alias llls -alF alias lals -A alias lls -CF export NPM_CONFIG_CACHE/workspace/.cache/npm export PIP_CACHE_DIR/workspace/.cache/pip mkdir -p /workspace/.cache/npm /workspace/.cache/pip 2/dev/null || true EOF然后在每个容器的~/.bashrc里加一行 source用 grep 判断避免重复追加grep -qxF [ -f /workspace/.shared_bashrc ] source /workspace/.shared_bashrc ~/.bashrc || \ echo [ -f /workspace/.shared_bashrc ] source /workspace/.shared_bashrc ~/.bashrc source ~/.bashrc3.3 Docker 挂载验证步骤假设你的 Docker 启动命令里已经挂载了 workspace验证挂载是否生效可以按下面几步走# 1. 确认 workspace 挂载点 mount | grep workspace # 2. 确认共享 bashrc 可读 ls -l /workspace/.shared_bashrc # 3. 确认环境变量已注入 python3 - PY import os for k in [TAOTOKEN_API_KEY, CONTEXT7_API_KEY, SILICONFLOW_API_KEY]: print(f{k}: {OK if os.environ.get(k) else MISSING}) PY # 4. 确认 config.toml 存在且语法正确 ls -l ~/.codex/config.toml如果第 3 步输出 MISSING说明 bashrc 没被 source检查~/.bashrc里那行 source 语句是否在非交互式 shell 下也能执行。VS Code 的 Codex 插件进程不一定继承.bashrc这种情况需要 Reload Window 或重连 Remote-SSH。4. 验证 MCP 与 Skills 是否真正生效4.1 手动测试 MCP server 能否启动stdio 类型的 MCP 不建议手动长期后台运行Codex 会根据command和args自动拉起。手动运行只用于排错# Context7 timeout 10s npx -y upstash/context7-mcp echo context7 exit$? # Sequential Thinking timeout 10s npx -y modelcontextprotocol/server-sequential-thinking echo sequential-thinking exit$? # arxiv MCP mkdir -p /workspace/arxiv-mcp-server timeout 10s env WORK_DIR/workspace/arxiv-mcp-server SILICONFLOW_API_KEY$SILICONFLOW_API_KEY \ npx -y langgpt/arxiv-mcp-serverlatest echo arxiv exit$? # drawio MCP timeout 10s npx -y next-ai-drawio/mcp-serverlatest echo drawio exit$?如果返回124通常表示该 stdio MCP server 能正常启动只是在等待 MCP client 输入属于正常现象。如果返回其他非零值说明依赖缺失或包名有误。4.2 检查 TOML 语法Python 3.11 以上自带tomllib可以直接校验python3 - PY import os try: import tomllib except ModuleNotFoundError: print(Python 3.11, skip TOML check.) raise SystemExit(0) path os.path.expanduser(~/.codex/config.toml) with open(path, rb) as f: tomllib.load(f) print(config.toml OK) PY输出config.toml OK说明没有 duplicate key 或语法错误。4.3 检查 Skills 是否被扫描到find ~/.agents/skills -maxdepth 3 -name SKILL.md -print如果 Skills 放在共享目录/workspace/.agents/skills需要在每个容器里做软链接mkdir -p ~/.agents rm -rf ~/.agents/skills ln -s /workspace/.agents/skills ~/.agents/skills对于层级较深的子 skills比如ai-infra-skills/.claude/skills/01-server/SKILL.md普通扫描器不一定能发现需要把子 skill 软链接到顶层for d in ~/.agents/skills/ai-infra-skills/.claude/skills/*; do if [ -f $d/SKILL.md ]; then nameai-infra-$(basename $d) ln -sfn $d $HOME/.agents/skills/$name echo linked: $HOME/.agents/skills/$name - $d fi done4.4 Reload Window 是必须步骤修改 MCP 配置或环境变量后旧 Codex 会话不会热加载。推荐顺序保存~/.codex/config.tomlsource ~/.bashrcVS Code 执行Developer: Reload Window新建 Codex 会话如果仍不生效执行Remote-SSH: Kill VS Code Server on Host后重连实测下来Reload Window 之后所有 MCP 工具都能恢复显示。5. 本篇常见错误排查5.1 duplicate key 报错报错信息failed to load configuration: /root/.codex/config.toml:15:11: duplicate key原因是多次用cat 追加配置导致同名 TOML table 重复出现[projects./workspace] trust_level trusted [projects./workspace] trust_level trustedTOML 不允许同一个 key 或 table 重复定义。解决方式是备份后重建cp ~/.codex/config.toml ~/.codex/config.toml.bak.$(date %Y%m%d_%H%M%S) 2/dev/null || true然后手动编辑删除重复的 table。添加新 MCP 前先 grep 检查grep -n ^\[mcp_servers\.context7\] ~/.codex/config.toml grep -n ^\[mcp_servers\.sequential-thinking\] ~/.codex/config.toml grep -n ^\[projects\./workspace\] ~/.codex/config.toml5.2 MCP 面板只显示 codex_apps这个现象说明 Codex 当前只加载了用户级~/.codex/config.toml没有加载项目级/workspace/.codex/config.toml里的 MCP server。常见原因VS Code 当前打开的根目录不是/workspace而是某个子目录Codex 会话是在 MCP 配置修改前创建的旧会话没有热加载项目级配置没有被 trustVS Code Codex 插件没有 Reload Windowconfig.toml有 duplicate key导致整个配置加载失败最稳的解决方式是把 MCP server 写入用户级~/.codex/config.toml不依赖项目级配置。5.3 /root/workspace 与 /workspace 路径不一致检查结果pwd -P # /workspace/.codex readlink -f /workspace # /workspace readlink -f /root/workspace # /workspace说明/root/workspace是/workspace的软链接实际指向同一目录。所以 MCP 不显示的根因不是路径不一致而是项目级配置没被加载。5.4 npx 依赖缺失很多 MCP 用 npx 启动每个 Docker 内部都需要检查node -v npm -v npx -v python3 --version如果缺失apt update apt install -y nodejs npm5.5 环境变量在插件进程里读不到.bashrc新增环境变量后VS Code Codex 插件进程不一定立刻继承。需要 Reload Window 或重连 Remote-SSH。如果还是不行检查~/.bashrc里的 source 语句是否在非交互式 shell 下也会执行必要时把 export 语句放到/etc/profile.d/下。6. 后续规范与统一接入建议把 MCP 和 Skills 的长期维护规范固定下来能省掉大量重复排查时间。MCP 规范MCP server 优先写入用户级~/.codex/config.toml共享项目级/workspace/.codex/config.toml可以保留但不要依赖它作为唯一来源不要反复cat 追加同名 table添加前先 grep 检查是否存在API Key 用env_vars不直接写入config.toml修改后必须 Reload WindowSkills 规范每个 skill 必须有SKILL.md可共享的 skills 放/workspace/.agents/skills每个 Docker 用软链接把~/.agents/skills指向共享目录深层子 skills 用软链接暴露到顶层修改或新增后 Reload Window 或新建 Codex 会话多 Docker 共享结构/workspace/ ├── .codex/config.toml # 可选项目级 MCP 配置 ├── .agents/skills/ # 共享 skills ├── AGENTS.md # 项目级 Codex 使用规则 ├── .shared_bashrc # 共享环境变量和 alias └── arxiv-mcp-server/ # arxiv MCP 工作目录每个 Docker 独立维护~/.codex/config.toml中的最终 MCP 配置、Codex 登录状态、API Key 环境变量、node/npm/python 依赖。Key 统一管理这块用 TaoToken 的 API Keys 页面创建 Key 后通过共享 bashrc 注入到所有容器避免每个容器单独配置。需要验证模型连通性时用模型对话页快速测试长期编码或 Agent 场景可以看 Coding Plan 的额度方案。接入细节参考接入文档API 端点统一用https://taotoken.net/api。最后提醒一个容易忽略的点如果想让所有 Docker 共用 bashrc不建议直接把~/.bashrc软链接为同一个文件因为不同容器可能有自己的 conda、CUDA、PATH 配置。推荐每个容器保留自己的~/.bashrc只 source 共享文件/workspace/.shared_bashrc这样既能统一 Key又不会破坏各容器的独立环境。