We've had no 5h limit in Codex plus and pro for a few days. Do you think it is better or are you finding it difficult to manage the usage included in the weekly limit effectively? If we were to make this different, what should it look like in an ideal world?
这几天里，我们在 Codex plus 和 pro 中没有设置 5 小时限制。你觉得这样更好吗，还是说你发现很难有效管理每周限额中包含的使用量？如果我们要把这件事改成另一种方式，在理想情况下它应该是什么样子？
On file deletions. We’ve investigated a handful of reports where GPT-5.6 unexpectedly deleted files. What we have found is that this most commonly occurs when: - Full access mode is enabled and codex is run without sandboxing protections, including without auto review being enabled - The model attempts to override the $HOME env var to define a temporary directory. - The model makes an honest mistake and mistakenly deletes $HOME instead. This is of course not how we want the system to behave, even when a user operates the model in full-access mode without the safeguards of our sandbox or without using auto review which checks for these kinds of high risk actions and rejects them. We are taking steps to mitigate this risk including by updating the developer message, guiding more users towards safer permission modes, and adding additional harness safeguards. Even though this happens extremely rarely, we’ll share a detailed post-mortem in the coming days that goes into more details and what we are doing to minimize risks further.
关于文件删除。我们调查了少量关于 GPT-5.6 意外删除文件的报告。我们发现，这种情况最常见于以下情形：- 启用了 full access mode，并且运行 codex 时没有 sandboxing（沙箱隔离）保护，包括没有启用 auto review - 模型尝试覆盖 $HOME env var（环境变量）来定义一个临时目录。- 模型出现了无心的错误，结果误删了 $HOME。本来这当然不是我们希望系统表现出来的行为，即使是在用户以 full-access mode 运行模型、且没有使用我们的 sandbox 防护，或者没有启用会检查这类高风险操作并予以拒绝的 auto review 时，也是如此。我们正在采取措施降低这项风险，包括更新 developer message、引导更多用户使用更安全的权限模式，以及增加额外的 harness safeguard（运行框架保护措施）。尽管这种情况极其罕见，我们仍会在未来几天分享一份详细的 post-mortem（事后复盘），更详细说明发生了什么，以及我们正在采取哪些措施来进一步降低风险。
Now that we merged ChatGPT and Codex, what should we merge next? What's the double or nothing move.
现在我们已经把 ChatGPT 和 Codex 合并了，接下来还应该合并什么？那个要么翻倍、要么归零的下一步动作是什么？