Long project chat becomes unrecoverable when request exceeds 1048576 characters input limit

[jeyarajcs]

Before filing

• Searched open and closed issues for the exact error text and the numeric limit; no matching Berd issue found.
• Reproduced/observed on the latest Berd release, v0.6.2.
• This report covers one issue: an oversized existing chat request becomes unrecoverable.

What's broken

A long-running project chat can fail with the following error once its accumulated request exceeds 1048576 characters:

Request failed: Internal error: { "details": "Input exceeds the maximum length of 1048576 characters." }

The chat does not provide a clear recovery path such as automatic compaction, truncation of older history, or a way to continue from a compacted summary.

Steps to reproduce

1. Launch Berd.
2. Open a project chat with substantial prior conversation history.
3. Continue using the chat until its accumulated request payload becomes very large.
4. Send another message.
5. Observe the request failure above.

The affected chat had prior history. The exact model and provider were not recorded.

What I expected to happen

Berd should proactively compact or otherwise reduce the existing chat context before the request exceeds the input limit, or provide a user-facing recovery action that preserves a concise summary and allows the chat to continue.

What actually happened

The request was rejected with the 1,048,576-character limit error. Retrying the same message did not provide a recovery path; starting a new chat was required as a workaround.

How often does it happen?

Once — I have not been able to reproduce it independently.

Berd version

0.6.2

Operating system

macOS (Apple Silicon)

Model and provider

Unknown — not recorded for the affected chat.

Relevant log output

No relevant log output found for the exact error text or numeric limit in the Berd application logs.

Other context

This occurred in a chat inside a Berd project. The error suggests the full accumulated conversation/request context is being submitted before a successful compaction or other overflow recovery step.

[jeyarajcs]

Reopening with a root-cause analysis — this turned out to be traceable end to end, and it should be fixable in Berd by just bumping the pinned Goose backend.

Root cause

The error is a collision between two components, not a Berd bug per se:

1. The 1,048,576-character cap belongs to Codex. The Codex CLI caps a single turn's user input at MAX_USER_INPUT_TEXT_CHARS = 1 << 20 characters (codex-rs/protocol/src/user_input.rs in openai/codex, enforced by validate_v2_input_limit in codex-rs/app-server/src/request_processors/turn_processor.rs). The @agentclientprotocol/codex-acp bridge wraps the resulting JSON-RPC error via RequestError.internalError({ details }), which is exactly the Internal error: { "details": ... } text goosed surfaces as Request failed: ....

2. goosed sends an unbounded "handoff context memo." When a chat is re-attached to a fresh agent process (app restart, model switch, unresumable agent session), the goosed shipped in Berd 0.6.2 (goosed 1.46.0) prepends a handoff memo to the first prompt: build_handoff_context_memo in crates/goose/src/acp/provider.rs joins the entire prior conversation with no size limit. On a long chat, that memo alone exceeds Codex's 1 MiB per-turn cap — which is why a short new message fails, and why retrying can never succeed (each retry rebuilds the same oversized memo, and history only grows).

claude-acp chats don't hit this particular failure: the cap is Codex-specific.

Fix already exists upstream

Goose commit e6b12beb ("fix(acp): bound the handoff memo so long sessions stay resumable", 2026-08-19, PR #11204) introduces crates/goose/src/acp/handoff.rs, capping the memo at min(30% of context window, 64k tokens) with elision of older tool output. Berd 0.6.2's bundled goosed was built on 2026-08-18 — one day before the fix landed — and the current goose-backend.lock.json pin (063694cf) is also behind it.

Suggested resolution: bump the Goose backend pin past e6b12beb and rebuild the sidecar. Optionally, Berd could also offer a user-facing recovery (compact/fork the chat) when a provider rejects input for size, since the current state leaves the thread permanently stuck.

Reproduction detail (filling in the "unknown" from the original report)

The affected chat ran on the codex-acp harness (GPT 5.6). The error appeared after the accumulated conversation grew large and the session was re-attached, matching the handoff-memo path above.