bug: 少量 Codex 会话未加载 cindy MCP，TapTap Maker 同时在 Cindy 与本地会话不可用

### 问题描述 / What happened

目前收到约 3–5 名用户反馈：在 Cindy 的 Codex 会话中调用 TapTap Maker 插件时，插件指令和工具清单已经作为文本进入上下文，但当前会话没有加载 `cindy` MCP 提供的 `ghost_list` / `ghost_call`，因此 Agent 无法真正调用 TapTap Maker。

大部分用户使用正常，问题仅在少量用户或少量环境中出现，当前尚未获得稳定的环境级复现条件。

用户首次反馈中的 Agent 诊断为：

```text
确认了——当前会话中确实无法调用 TapTap Maker 插件。

诊断结果

- 我的可用工具中没有 ghost_call / ghost_list（Cindy 总机桥接通道未接通）
- MCP 资源列表中只有 Adobe、Figma、Sites 等插件，没有 TapTap Maker 的 MCP 服务端
- 插件指令和工具清单虽然作为文本注入了上下文，但实际调用通道不存在
```

问题出现后，同一设备上的本地 Codex 会话也无法使用 TapTap Maker，并返回：

```text
当前会话里 Maker MCP 不可用：taptap-maker skill 已安装，但它依赖的
ghost_list / ghost_call 插件入口没有加载，因此无法调用 maker_status 验证连接。
需要在 Cindy 中启用或重新加载 TapTap Maker 插件后再试。
```

这里“启用或重新加载插件”的提示可能误导用户：从现象看，TapTap Maker skill 与插件指令已经存在，缺失的是更上游的 `cindy` MCP 工具入口。

### 环境 / Environment

- Cindy 版本或 commit：多个用户反馈，具体版本待补充
- 平台与版本：待逐个收集；需重点确认 Windows、公司代理/PAC 和系统代理环境
- 安装方式：正式客户端，具体渠道待补充
- 影响规模：目前约 3–5 名用户反馈，大部分用户正常
- Agent：Codex
- 会话类型：Cindy 会话和同设备本地 Codex 会话均观察到；需继续确认是否包含 SSH `remoteHostId` 会话

### 复现步骤 / Steps to reproduce

当前尚未稳定复现。根据用户反馈，可通过以下步骤观察故障状态：

1. 在 Cindy 中安装并启用 TapTap Maker 插件；
2. 创建或打开 Codex 会话；
3. 通过 TapTap Maker 插件入口发送需要调用 Maker 的请求；
4. 插件指令和工具清单进入会话上下文；
5. Agent 检查当前工具后发现不存在 `ghost_list` / `ghost_call`，无法调用 Maker；
6. 在同一设备的本地 Codex 会话中再次尝试使用 `taptap-maker` skill；
7. 本地会话同样报告 `ghost_list` / `ghost_call` 未加载，无法调用 `maker_status`。

### 期望行为 / Expected behavior

- 本地 Codex 会话应始终加载 `cindy` MCP 的稳定工具面，包括 `ghost_list` 和 `ghost_call`；
- TapTap Maker 插件已安装并启用时，Agent 应能通过 `ghost_call` 调用其工具；
- 即使没有安装任何 Ghost 插件，`cindy` MCP 也应存在，只由 `ghost_list` 返回空清单；
- 如果 MCP bridge 无法建立，应向用户展示可诊断、可恢复的错误，而不是继续创建一个缺少全部 Cindy MCP 工具的会话；
- 如果某类远程会话明确不支持 Cindy MCP，则 UI 不应继续展示或注入必然无法执行的 TapTap Maker 插件指令。

### 实际行为 / Actual behavior

- TapTap Maker skill、插件指令和工具描述已经加载；
- `ghost_list` / `ghost_call` 未出现在当前 Agent 工具面；
- Agent 只能读到“必须调用插件”的文本要求，却没有实际调用通道；
- Cindy 出现问题后，同设备本地 Codex 会话也无法使用 TapTap Maker；
- 用户会被提示重新启用 TapTap Maker，但重新启用插件未必能恢复缺失的 `cindy` MCP bridge。

### 已确认的代码事实

1. `cindy` MCP 按设计应恒定注册，不受具体 Ghost 插件开关控制：

```text
apps/desktop/src/main/mcp-integrations/mcp-providers.ts
packages/cindy-tools/src/ghost/mcpServer.ts
```

`createCindyGhostsMcpServer()` 固定注册 `ghost_list` / `ghost_call`。因此缺少这两个工具不是“TapTap Maker 未安装”的正常表现。

2. 本地 Codex 通过 loopback Streamable HTTP bridge 消费 Cindy 的 in-process MCP：

```text
apps/desktop/src/main/mcp-integrations/codexEnvironment.ts
apps/desktop/src/main/mcp-integrations/codexHttpBridge.ts
```

3. bridge 准备失败时，当前代码会记录错误后继续启动不带 Cindy MCP 的 Codex：

```text
apps/desktop/src/main/maker-host/index.ts
packages/maker-core/src/agents/codex/index.ts
```

对应日志：

```text
codex MCP bridge prep failed, continuing without lizi MCP
```

4. SSH 远程 Codex 会话检测到 `remoteHostId` 后会返回空 MCP 启动参数；但 Renderer 仍可能读取本机 Ghost 清单并注入插件指令：

```text
apps/desktop/src/main/maker-host/index.ts
packages/maker-core/src/agents/codex/index.ts
apps/desktop/src/renderer/components/new-chat/ChatInput.tsx
```

5. loopback bridge 依赖 `127.0.0.1:`。代码已专门补充 `NO_PROXY=127.0.0.1,localhost,::1`，注释记录了公司代理/PAC 导致 Codex MCP 返回 `UnexpectedContentType`、全部 Cindy 工具消失的历史风险：

```text
packages/maker-core/src/agents/codex/env-builder.ts
```

### 与 Maker MCP Windows npx 安装缺陷的关系

已知 `@taptap/maker` 的 Windows MCP 安装器曾无条件生成：

```text
cmd.exe /d /s /c npx.cmd -y -p @taptap/maker taptap-maker
```

在客户端 PATH 没有 `npx.cmd` 时会导致独立 Maker MCP 启动失败。但该问题发生在 Maker MCP 启动层；本 issue 的故障发生得更早，连 Cindy 自己的 `ghost_list` / `ghost_call` 都不存在。

因此当前不应把 Maker 安装器缺陷作为本 issue 的既定根因。只有在 `ghost_call` 正常存在、调用 Maker 后才出现 `npx.cmd is not recognized` 时，才属于该独立问题。

### 当前根因假设 / Investigation hypotheses

现有证据只能确定故障点位于 `cindy` MCP bridge 的注册或连接链路，尚不能在以下条件中唯一归因：

1. 受影响会话为 SSH 远程 Codex，会按当前实现跳过本地 Cindy MCP；
2. 本地 HTTP bridge 启动失败，异常被吞后 Codex 继续降级启动；
3. 公司代理、PAC、系统代理或安全软件阻断/改写 `127.0.0.1` bridge 请求；
4. 受影响客户端版本未包含或未正确应用 loopback `NO_PROXY` 处理；
5. 共享 Codex app-server / MCP bridge 的缓存或重启生命周期异常，导致后续本地会话复用缺少 MCP 的 host。

### 建议补充的诊断信息

从一名受影响用户收集以下脱敏信息即可快速分流：

- Cindy 完整版本；
- OS 与架构；
- 会话是否为 SSH Remote，数据库/会话中的 `remoteHostId` 是否非空；
- 是否启用公司代理、PAC、系统代理、TUN 或安全软件；
- `HTTP_PROXY`、`HTTPS_PROXY`、`ALL_PROXY`、`NO_PROXY` 是否设置（只记录是否设置和脱敏后的 host，不记录凭证）；
- main 日志中以下关键字：

```text
http bridge listening
codex MCP bridge wired
codex MCP bridge ready
codex MCP bridge prep failed
UnexpectedContentType
rejected unauthenticated request
rejected non-localhost request
```

- Codex app-server 的 MCP server/tool 列表中是否存在 `cindy`、`ghost_list`、`ghost_call`；
- 重启 Cindy、重启 Codex host、重新启用 TapTap Maker 后分别是否恢复。

### 建议验收标准

- [ ] 本地 Codex 新会话稳定包含 `cindy` MCP 的 `ghost_list` / `ghost_call`；
- [ ] bridge 准备或初始化失败时不再静默创建一个缺少全部 Cindy MCP 的会话；
- [ ] 错误信息能区分 bridge 启动失败、loopback 连接失败、代理改写和远程会话不支持；
- [ ] 日志包含脱敏后的 bridge 生命周期、server 名和失败阶段；
- [ ] 公司代理/PAC/系统代理环境下验证 loopback bridge 不经过代理；
- [ ] Windows 与 macOS 至少各完成一次本地 Codex + TapTap Maker 回归；
- [ ] SSH Remote 不支持 Cindy MCP 时，不展示或注入不可执行的 TapTap Maker 插件指令；或补齐远程 bridge 支持；
- [ ] MCP host 重启、插件重载和会话重建后不会复用缺少 `cindy` MCP 的缓存状态；
- [ ] 增加“bridge 准备失败”和“远程会话 UI 仍注入 Ghost 指令”的回归测试。

Start with apps/desktop/src/main/mcp-integrations/codexEnvironment.ts and codexHttpBridge.ts, then trace bridge failure handling in apps/desktop/src/main/maker-host/index.ts and packages/maker-core/src/agents/codex/index.ts. Reproduce while checking the listed bridge and MCP logs under local, proxy/PAC, and SSH sessions; inspect env-builder.ts and ChatInput.tsx for loopback and remote-session behavior. Done means the acceptance checklist passes, including regression coverage for bridge failure and remote UI injection.

Written by the indexing model from the issue text.