该内容描述了代码审查中建议提交的限制条件：建议只能逐行应用，不能用于已关闭的拉取请求、已删除行或待处理审查，且需修改现有代码才能生效。

该建议可添加至一个批次中，并作为单次提交应用。但当前建议无效，因为代码未作任何更改。在拉取请求关闭、查看部分更改、或处理已删除行时，建议均无法应用。每行仅能添加一条建议，且必须修改现有代码才能生成有效建议。若建议已被应用或标记为已解决，则无法再操作。此外，待审核中的建议、多行评论、以及拉取请求排队等待合并时，均无法应用建议。当前无法立即应用该建议，请稍后再试。

根据评论内容，总结如下：

核心观点：OpenAI Codex上下文窗口从372k降至272k，引发用户对性能、成本和实用性的讨论。

1. 支持/理解缩减的观点（认可度：中等） - 缩减是成本/延迟的权衡，而非能力问题，大多数会话不需要372k tokens。 - "Context size cuts like this are usually a cost/latency tradeoff rather than a capability one" (cyb3ralbert) - "serving a smaller window is cheaper and keeps latency in check" (cyb3ralbert) - 良好的压缩机制可弥补窗口缩小，对实际体验影响不大。 - "Codex compaction is really quite good. Smaller context doesn't really harm me." (cmrdporcupine) - "You just need good compaction and a memory system... If you don't have that 1M tokens won't really save you either." (weeksie)

2. 反对/担忧缩减的观点（认可度：较高） - 压缩导致细节丢失，影响复杂任务（如多论文分析、大型代码库）。 - "the level of detail you lose across compaction is wildly too much for most things that I do" (tekacs) - "372 was not perfect, but it was so much better and a godsend. It turned that 12 to 20% into more like 40%." (tekacs) - 1M上下文应是前沿模型的基本要求，尤其对编程工作流。 - "1M should be table stakes for frontier models at this point for programming." (hakanderyal) - "I have rule files that... cost 60-80k tokens... With 1M context I deleted all of those." (hakanderyal)

3. 其他重要发现（认可度：中等） - 系统提示新增了防止破坏性操作的指令，修复了可能误删用户目录的bug。 - "Before taking a destructive action: Make sure the action is clearly within the user's request." (simonw) - "Looks like the fix for this bug where Codex would occasionally accidentally delete your entire home directory" (simonw) - 部分用户认为模型在250k后性能下降，窗口大小并非关键。 - "claudes/codex performance suffers after 250k anyway and my workflow reset after every 200 so this is a non-issue" (miranaproarrow) - "Does the context size really matter that much if the 'dumb zone' starts around 120-150k anyway?" (fandorin)

总结： 用户对上下文窗口缩减反应两极。支持者认为压缩技术有效，成本优化合理；反对者强调细节丢失影响复杂任务，并呼吁1M上下文成为标配。同时，安全改进（防误删指令）获得认可，但部分用户质疑模型在长上下文下的实际性能。