Codex preview job blocked by fixed briefing capacity with no actionable recovery path

[paunchydroid]

Describe the bug / 描述 bug

An existing Distilly job cannot resume because its briefing exceeds
the capacity recorded for the Codex adapter. The error recommends
using a larger-capacity host or reducing the research batch, but
there appears to be no supported capacity setting for this adapter.

Environment

• Host: Codex CLI 0.146.0
• Distilly: 0.1.0-preview.1
• Platform: Linux ARM64 / Raspberry Pi
• Product line: distilly-plugin
• Node.js version: v22.23.2
• Distilly commit: 5525a4e

Steps to reproduce / 复现步骤

1. Resume an existing job with a serialized briefing of 85,819 bytes.
2. Request a fresh briefing through distilly_pending, action "brief".
3. Observe briefing_too_large.

Actual behavior / 实际行为

The response reports:

• Serialized briefing: 85,819 bytes
• maximumToolResultBytes: 65,536 bytes
• maximumInputTokens: 65,536 tokens

The job remains pending and no patch or commit is created.

Increasing model_context_window to 128000, retaining
tool_output_token_limit = 100000, and fully restarting Codex did
not change the reported Distilly limits.

Inspection of the installed source found these capacity values
in packages/cli/src/host-capacity-fixtures.ts. The production
adapter uses that version-specific fixture.

Expected behavior / 期望行为

Please provide a supported recovery path for oversized briefings:
a tested larger-capacity binding, capability negotiation, or a
documented way to split/reduce the pending batch while preserving
its evidence.

The error should explain when changing Codex context settings
cannot affect the adapter's recorded capacity.

Is this a known preview limitation, and what is the recommended
way to resume an existing affected job?

[paunchydroid]

Thanks @harr1sz — recovery testing on my Raspberry Pi succeeded using isolated copies of the affected job.

Tested #165 at ae825fbe711eda0e2058f514670cd2b606b77e64 and #164 at 2ea4f172b6829dc86990beaf4ee70dfe38183cb6, individually and together.

• fix: recover oversized briefings through files / 超大 briefing 文件恢复 #165: 19/19 focused tests passed. The ordinary briefing reproduced briefing_too_large at 85,819 bytes; file recovery succeeded and produced a durable 33-claim suspended candidate while preserving the existing 31-claim current profile. Actual CLI cancellation released the lease, and an immediate retry acquired it successfully.
• fix: preserve pending research after corrections / 修正后保留待处理资料 #164: 12/12 focused tests passed. In the combined real-data test, correction preserved all nine pending research sources, and subsequent recovery succeeded.
• Build, typecheck, formatting, documentation, boundaries (49/49), build artifacts (34/34), and plugin checks (13/13) passed.

The broader checks were not completely green on this device: the parallel Vitest run had 1,014 passes and seven failures across five files (child-process phase waits and timeouts). Those five files then passed 44/44 with one worker and unchanged timeouts, suggesting resource contention. ESLint stopped after Node exhausted its approximately 1 GB heap; Playwright reported Chromium unsupported on this ARM platform, so browser tests could not run.

Environment clarification: Node is v22.23.2 with process.arch = "arm" (32-bit ARM runtime), despite the ARM64 description in my original report.

My live job, installed plugin, and original checkout remain unchanged. Could a maintainer approve/start the pending GitHub Actions workflows for #164 and #165 and confirm the checks pass before I update the installation and resume the live job? Thanks!