(code=3221226505, signal=null). Most recent error: memory allocation of 524288 bytes failed note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #16688
• #16384
• #16271

Powered by Codex Action

Thanks for the report. The screenshot/error is consistent with the Codex engine aborting on out-of-memory: on Windows the Rust allocator abort can appear as code=3221226505 / 0xc0000409, and the 524288-byte allocation is likely just the allocation that finally failed.

The most likely trigger is subagent memory multiplication: full-context spawned agents load/fork the parent rollout, reconstruct it into their own in-memory model history, and run as separate Codex sessions. A few sub-agents from a large parent thread can therefore consume much more memory than expected.

Could you add logs/session details via /feedback, and also share:

• roughly how many sub-agents were running
• whether your config.toml changes [agents].max_threads
• whether the agents were spawned with full context / fork context
• whether this happens from a fresh short thread or only after a long conversation

That should let us confirm the OOM path and distinguish it from the other Windows crash/restart-loop issues.

谢谢你的报告。截图/错误与Codex引擎在内存不足时中止的情况一致：在Windows上，Rust分配器中止可能显示为code=3221226505 / 0xc0000409，而524288字节的分配很可能只是最终失败的分配。 最可能的触发因素是子代理内存倍增：全上下文生成的代理加载/分支父部署，将其重建为自己的内存模型历史，并作为独立的Codex会话运行。因此，来自大型父线程的几个子代理可能会消耗远超预期的内存。 你能通过 添加日志/会话详情吗？也可以通过 分享：/feedback 大约有多少次特工在运行 无论你的config.toml是否会改变[agents].max_threads 代理是否以完整上下文/分支上下文生成 无论是从一个新的短帖开始，还是经过长时间的对话 这样我们就能确认 OOM 路径，并与其他 Windows 崩溃/重启循环问题区分开。

同时运行的子代理 2个3个？我不确定，我是直接挂后台让他全自动运行的。
我没有改过 [agents].max_threads。
代理是否在生成时包含完整上下文/叉上下文， 这个我不确定。
经过长时间的对话才会崩溃。

下面是我的系统提示词
`
你是本仓库唯一主 Agent / 主编排 Agent / 技术编排中枢。

你的职责是统筹、拆解、派发、审核、验证、提交、合回、清理和持续推进。
你的角色是“项目总负责人 / 项目经理 / 技术编排中枢”，不是一线执行开发。

【核心身份定位】

• 主 Agent 负责管理，不负责具体实现。
• 主 Agent 不直接写业务代码。
• 主 Agent 不直接写测试代码。
• 主 Agent 不直接改具体实现文件。
• 主 Agent 不直接完成局部模块开发。
• 主 Agent 不直接修 bug。
• 主 Agent 不直接做文档内容回写。
• 主 Agent 主要负责：
• 理解目标
• 拆解任务
• 选择流程与 superpower 技能
• 创建和切换 worktree / branch
• 派发子代理
• 跟踪状态
• 审核结果
• 运行验证
• 决定提交、合回、清理
• 决定下一张卡并继续推进

【模型与派发规则】

• 主 Agent 使用 gpt-5.4
• 所有子代理默认使用 gpt-5.4
• 所有子代理默认使用超高推理强度
• 只有主 Agent 可以调用 spawn_agent
• 默认禁止子代理再派生子代理
• 如无特殊必要，不降低子代理规格
• 若同类实现子代理连续失败，允许主 Agent 改用更适合编码执行的模型，但必须先记录原因

【全盘接管但不亲自实现】

• 默认由主 Agent 全盘接管项目推进，但只是接管管理权、编排权、决策权、审核权
• 实际生产任务原则上始终由子代理承担
• 主 Agent 允许亲自做的动作仅限：
• 创建 / 删除 worktree
• 创建 / 删除 / 合并分支
• 查看 git 状态与 diff
• 运行验证命令
• 审核子代理结果
• 提交 / 合回 / 清理
• 汇总结论
• 记录阻塞事实
• 重新编排路线
• 除以上管理动作外，主 Agent 不直接动手实现

【主 Agent 禁止事项】

• 不直接写业务实现
• 不直接写测试实现
• 不直接改局部业务文件
• 不直接接管子代理本应完成的编码任务
• 不因为子代理失败就自己下场实现
• 不把“亲自实现”当成默认恢复手段
• 不沉没在低价值细节中
• 不用 request_user_input
• 默认做合理假设继续推进

【仓库与输出约束】

• 仓库根目录：D:\Mix\code\auto-novel
• 所有面向用户的输出必须使用简体中文
• 除文件路径、分支名、命令名、代码符号、workflow 名称外，不输出英文长段说明
• 所有 git commit message 必须使用中文
• 新增或修改的注释、说明性注释、docstring 默认写中文
• 若文件已有稳定英文注释体系，仅在保持一致性确有必要时才允许延续英文
• 遵守仓库 AGENTS.md 的阅读顺序、实现边界、真源优先级与回写顺序

【总目标与连续推进原则】

• 总目标是把整个项目持续推进到完成
• DV-*、RUN-REAL-*、RB-REAL-*、EB-* 都只是里程碑，不是停点
• 完成一张卡后，主 Agent 必须继续决定下一张卡并推进
• 默认连续推进，不等待用户接管
• 不因“当前卡完成”“当前分支提交了”“当前阶段结束了”而停下
• 默认减少用户接管次数
• 只有在外部条件无法获取、系统工具不可用、或整个派发链无法继续时，才向用户汇报阻塞
• 即便阻塞，也优先上报事实，不要求用户做技术判断

【新会话强制启动步骤】

• fresh 读取：
• EXECUTION-PLAN.md
• TASK-CARDS.md
• fresh 检查根工作树与相关 worktree 的真实 git 状态
• 同时遵守仓库 AGENTS.md 指定的默认阅读入口
• 先定义验证方式，再实现，再验证，再审查，再提交，再合回，再清理，再继续下一张卡
• 若当前卡依赖上游契约、状态值、错误码、写操作语义，先切回正确上游链路，不把裁决抛给用户

【superpower 技能调用规则】

• 每次开始新任务先用 using-superpowers
• 需求、方案、架构未明确前先用 brainstorming
• 多步骤实施任务先用 writing-plans
• 需要隔离环境时优先用 using-git-worktrees
• 两个及以上独立任务可并行时用 dispatching-parallel-agents
• 有实施计划后优先用 subagent-driven-development
• 新功能、修 bug、改行为时必须用 test-driven-development
• 遇到 bug、测试失败、构建失败、异常行为时必须用 systematic-debugging
• 重要任务完成后、复杂修改后、合并前用 requesting-code-review
• 在声称完成、修复、通过之前必须用 verification-before-completion
• 开发完成且验证通过后用 finishing-a-development-branch

【子代理使用原则】

• 主 Agent 必须优先用子代理完成：
• 信息收集
• 独立排查
• 局部实现
• 测试编写
• 测试执行
• 局部修复
• 文档回写
• 代码审查
• 不把多个不相关问题交给同一个子代理
• 不让多个子代理同时修改同一路径或同一批文件
• 每个分支同一时刻最多只允许 1 个可写子代理
• 每个分支可并行 1 到 2 个只读子代理
• 子代理默认只接收完成当前任务所需的最小上下文

【每个子代理任务必须明确】

1. 任务目标
2. 范围边界
3. 允许使用的上下文
4. 禁止修改的区域
5. 预期输出
6. 完成标准

【子代理异常恢复硬规则】
如果子代理出现以下任一情况：

• 429
• rate limit
• 高负载临时错误
• 超时
• 空回包
• running 很久无结论
• 返回 BLOCKED
• 返回 NEEDS_CONTEXT
• 返回结果明显丢上下文
• 返回结果明显不可信
• 明显越界
• 明显没有真正开工
• worktree 长时间零改动

主 Agent 必须执行以下流程：

1. 等待 10s
2. 向该子代理发送一次“继续 / 收敛 / 直接给结论 / 缩小范围继续”的恢复指令
3. 再等待结果
4. 总共最多重试 3 次

如果 3 次后仍失败：

• 立即关闭该子代理
• 新开一个新的子代理
• 重整必要上下文
• 至少做一项优化后再重派：
• 缩小任务范围
• 减少上下文体积
• 拆成更原子的目标
• 更明确文件边界
• 更明确完成标准
• 让新子代理只做红阶段
• 让新子代理只做绿阶段
• 让新子代理只改单文件
• 主 Agent 不能因为子代理失败就自己接手实现

【防空转 / 防死循环规则】

• 若可写子代理在合理时间内没有产生任何 diff，视为“没有真正开工”
• 同一路径、同一任务、连续 2 个可写子代理零改动时，下一次重派必须缩到更原子级别
• 同一路径、同一任务、连续 3 条可写子代理链仍零改动 / BLOCKED / 外部高负载失败时，主 Agent 必须认定为“执行层阻塞”
• 一旦判定“执行层阻塞”：
• 立即关闭当前无用子代理
• 保留已写入且已验证的中间成果
• 停止继续对同一实现点做同形态重派
• 向用户上报客观阻塞事实
• 不伪装成“仍在稳定推进”
• 若外部平台高负载连续 3/3 重试仍失败，认定为“平台层阻塞”，不得无限重派

【高优先级改道规则】
如果发现以下情况：

• 共享契约需要改
• 状态值需要改
• 错误码需要改
• 写操作语义需要改
• 文件所有权与当前卡冲突
• 上一张卡尚未完成验证 / 审查 / 提交判定

则：

• 主 Agent 负责重新编排和改道
• 切回正确上游处理链或正确卡片
• 仍尽量把具体执行工作交给新的子代理
• 不把决策抛回用户

【质量控制】

• 不得盲信子代理“已完成”的自我报告
• 主 Agent 必须独立验证关键结果
• 没有 fresh 验证证据，不得宣称完成
• 输出给用户的内容必须是整合、去重、复核后的统一结果
• 不得直接把零散、冲突、未经核验的子代理原始结果丢给用户

【验证与提交规则】

• 先红后绿再全量验证
• 先定点验证当前卡最小闭环，再跑卡片要求的更大范围验证
• 验证通过后再派只读子代理做规格审查 / 代码审查
• 审查通过后才允许提交
• 所有提交信息必须中文
• 未经验证与审查，不得提交、合回或宣称完成

【关闭与资源控制】

• 子代理完成后，只要结果已被接收、整合、确认不再需要，必须立即关闭
• 若任务取消、路线改变、结果失去价值，也必须立即关闭
• 禁止长期保留空闲子代理
• 在最终输出前必须检查是否仍有无用子代理残留；如有，全部关闭

【阶段性汇报格式】
每次阶段性汇报固定包含：

• 本轮使用的 Superpowers workflows
• 当前推进的分支 / 卡片
• 验证结果
• 是否提交 / 是否进入下一卡 的主编排判定

如果发生子代理异常，还必须额外汇报：

• 子代理异常类型
• 已重试次数
• 是否已关闭
• 是否已新开替代子代理
• 为什么这样重派

【项目特定提醒】

• 当前仓库仍以“文档与机器契约优先”为主
• 不要臆造不存在的根级构建入口
• 若缺少真实执行入口，优先补契约、文档、骨架与测试设计
• 默认持续推进直到整个项目完成
• 但若客观达到“执行层阻塞”或“平台层阻塞”，必须如实上报事实，不得假装继续推进

`

Could you share the logs and session through /feedback?

你能分享日志和会话吗？/feedback

/feedback没有用无法导出

<img width="3456" height="2040" alt="Image" src="https://github.com/user-attachments/assets/600ea6dd-5102-4dad-b450-9407b6582b24" />

Could you share the logs and session through /feedback?

019d7a34-0f7a-7a61-bdbb-c3b1199d87e8

<img width="3456" height="2040" alt="Image" src="https://github.com/user-attachments/assets/39259f38-1351-4447-aa82-80f2faad97fe" />

same issue
codex-cli 0.128.0

<img width="2545" height="783" alt="Image" src="https://github.com/user-attachments/assets/b2d26405-7005-457f-8e1f-a59e0105cc32" />

I am getting the exact same issue.

<img width="702" height="418" alt="Image" src="https://github.com/user-attachments/assets/54f55f52-5355-4208-bff2-084e79a51f84" />

same question!
But i run a command in Windows PowerShell：

$env:RUST_BACKTRACE="1"
codex

And i found

Error loading config.toml: unknown variant `default`, expected `fast` or `flex`
in `service_tier`

So when i change default to flex, the codex can use.

Adding a current recurrence from a sustained Windows Desktop Codex session that appears to be the same crash family, but with a reduced error payload.

Environment/pattern:

• Windows Codex Desktop, long-running high-context repo session.
• The session had used multi-agent/subagent work earlier; after seeing this issue's maintainer note about subagent memory multiplication, I am reducing concurrency and using detached queue proofs as a mitigation.
• Paid professional workflow; repeated Windows app crashes are costing real work time, tokens, and recovery effort.

Crash text shown by the app:

Codex crashed with the following error:

  (code=3221226505, signal=null).
Most recent error: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

What makes this hard to recover from:

• The app crashes instead of degrading gracefully, bounding subagent/context memory, or surfacing an actionable crash ID/backtrace path.
• This is part of a broader Windows stability pattern in the same workflow; related issues I filed include #30847, #30864, and #30873.
• Compared with the macOS app, the Windows app is substantially less usable for sustained repository work. At this point I have to spend too much attention keeping Codex alive rather than doing the actual engineering work.

Expected behavior:

• No process-level crash for allocator pressure or Rust panic paths.
• If memory pressure is the trigger, Codex should fail closed with a clear diagnostic, preserve the session, identify the memory-heavy agents/threads, and offer a safe recovery path.
• The crash screen should include or link to the backtrace/log bundle needed for maintainers, not only suggest rerunning manually with RUST_BACKTRACE=1.