内存泄漏需通过codex monitor确认rss持续增长，再用--inspect和--trace-gc启动，chrome devtools抓取baseline与after_load快照对比，聚焦# new高且# deleted≈0的buffer/map/sharpimage等对象，结合retainers定位源码行；同时检查动态require和sharp.cache(false)配置。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当你发现 Codex 进程运行十几分钟后内存占用从 800MB 涨到 3.2GB，风扇开始狂转、输入延迟明显，说明不是瞬时峰值而是持续增长——这大概率是内存泄漏，必须用可验证的路径定位真实源头，不能靠重启蒙混过关。
确认是否真在增长
先排除误判：在终端执行 codex monitor --resource=mem --interval=1000，观察连续 5 次输出中 RSS（Resident Set Size）值是否稳定上升。若每秒涨 10–30MB 且无回落，进入下一步；若波动大但整体平台期明显，则可能是缓存未释放，非泄漏。
注意：【不要用 free -h 或任务管理器看总量】，它们反映的是系统级水位，无法关联到 Codex 进程本身。
分层抓取内存快照
这一步必须在 Codex 正常运行状态下操作，不要重启或 reload 配置。
第一步：在 Codex 启动时加调试参数启动——codex start --inspect=9229 --trace-gc。不加 --inspect 后续无法连接 Chrome DevTools，不加 --trace-gc 就看不到 GC 是否失效。
第二步：等待 Codex 空闲（无请求、无日志刷屏），打开 Chrome 浏览器访问 chrome://inspect → 点击 “Open dedicated DevTools for Node” → 切换到 “Memory” 面板 → 点击 “Take heap snapshot” 拍下第一份快照，命名为 “baseline”。
第三步：向 Codex 发起一组固定请求（例如连续 5 次调用 /genDoc 接口），等内存曲线明显抬升（建议等 RSS 增长 ≥400MB）后，立刻拍第二份快照，命名为 “after_load”。两次快照之间严禁重启进程，否则引用链断裂，对比失效。
配置 OpenClaw 多提供商认证与 OpenAI Codex OAuth 备用方案，实现自动模型切换，适用于多 OpenAI Codex 账户设置。
用 DevTools 对比定位泄漏对象
在 Memory 面板左侧选择第二份快照（after_load）→ 点右上角 “Comparison” → 基准选 baseline → 等待加载完成。
重点盯住 “# New” 列：找出构造函数名含 Buffer、Map、SharpImage、ContextCache 的条目。如果某类对象 # New 值 > 200 且 # Deleted ≈ 0，基本锁定为泄漏源。
点击该构造函数 → 右侧切换到 “Retainers” 标签页 → 展开最顶层的非系统模块调用链。例如看到 codex/lib/cache/session.js:87 → 说明第 87 行的 cache.set(sessionId, data) 没配 TTL，导致会话数据永久驻留。
【retained size 才是关键，shallow size 可忽略】——它代表这个对象及其所有强引用子对象的总内存，才是真实吞噬量。
验证泄漏是否来自外部依赖
方法一：检查动态 require 字符串
在 Codex 项目根目录运行：grep -r "require.*[" ./src/ | grep -v "node_modules/"。若返回 require(pkgName) 或 import(`${pkgName}/index.js`)，说明 depcheck 会漏掉这些包，它们可能在运行时反复加载并残留模块缓存。
方法二：检查 sharp 等图像处理库是否禁用缓存
打开 codex/lib/image/process.js，确认是否存在 sharp.cache(false) 调用。没有这句，每次调用都会在内存中缓存解码后的像素数据，且不会被 GC 回收。
