AIOS 的 Windows 更新：不只是“启动修复”，而是跨 CLI 可靠性链路加固¶
这次内容和 AIOS 核心能力直接相关，不是泛化的 Windows 使用技巧。
快速结论¶
AIOS 的关键链路是三层：
- 桥接层：
contextdb-shell-bridge.mjs负责 wrap / passthrough 决策 - 会话层：
ctx-agent负责 ContextDB 会话上下文注入与续跑 - 执行层：原生 CLI（
codex/claude/gemini）照常执行
本次 Windows cmd 包装器修复发生在第 1 层，但保护的是整条链路。
为什么这是 AIOS 的问题，而不是通用问题¶
如果没有 AIOS，.cmd 启动失败通常只是“工具起不来”。
在 AIOS 里，同一个问题会连锁影响：
- 会话连续性（
session -> context:pack -> inject） - 包裹策略（
repo-only/opt-in/all） - 依赖稳定入口的编排流程（orchestrate / subagent runtime）
所以这不是普通 shell 小修小补，而是 AIOS 工作流契约的一部分。
本次到底改了什么¶
在 shared process launcher + contextdb-shell-bridge 路径中，Windows cmd 包装器处理被加强：
- npm/cmd 启动器解析更稳
- 包装器入口不可解析时，fallback 的 shell 行为更安全
- 如果存在原生可执行文件，仍优先走原生路径
覆盖范围：Codex、Claude、Gemini 的包装器启动链路。
60 秒自检¶
拉最新 main，重启终端后执行：
codex
再开启 bridge 调试信号：
export CTXDB_DEBUG=1
codex
预期现象：
- cmd 包装器边界场景下不再频繁启动失败
- bridge 仍能正确做 wrap / passthrough 决策
- 不改日常命令也能继续走“跨 CLI + 有记忆”工作流
AIOS 视角的价值¶
这次修复保护的是完整链路：
shell wrapper -> contextdb-shell-bridge -> ctx-agent -> contextdb -> native CLI
在 Windows 上任何一环不稳，AIOS 的“跨 CLI 连续作业”承诺都会打折。这次更新就是把这一环补强。
FAQ¶
需要改命令吗？¶
不需要。继续用 codex / claude / gemini。
只是启动层修复吗？¶
修的是启动入口，但影响的是 AIOS 的上下文续跑与包裹策略稳定性。
会影响 token 成本吗？¶
不会直接影响。这次不涉及模型调用策略，聚焦进程与包裹可靠性。