Repository navigation
session: multi-MB inline attachment makes a session permanently fail to decode #55110
Closed as duplicate
Description
Description
Plugins
No response
OpenCode version
v2.0.28
Steps to reproduce
Prerequisites: opencode v2.0.28, no plugins/MCP configured. Reproduced on Windows 11.
- Open any session and attach a file large enough that its base64 encoding exceeds ~5,000,000 characters (roughly a 4 MB or larger binary file; e.g. a PDF or zip). Smaller attachments (up to ~500 KB base64) do NOT trigger the bug.
- Send the message so the attachment is stored inline (files[0].source.type === "inline").
- Trigger a session reload: restart the background service (
opencode service restart), or reopen the session, or callGET /api/session/{sessionID}/context.
Expected: the session loads normally and returns its history including the attachment.
Actual: the session can never be loaded again. Every load and every server start reports the same message id:
level=ERROR message="Failed to drain Session"
cause="Session.MessageDecodeError: Failed to decode message msg_... in session ses_..."
and GET /api/session/{sessionID}/context returns HTTP 500:
{"_tag":"UnknownError","message":"Unexpected server error. Check server logs for details.","ref":"err_..."}
Deterministic minimal reproduction of the root cause (Node/V8, same engine as Bun):
const re = /^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$/u;
re.test("A".repeat(5_000_000));
// RangeError: Maximum call stack size exceeded
Screenshot and/or share link
No response
Operating System
windows11
Terminal
windows
Activity
opencode-agent commentedon Oct 13, 2026
Thanks for the detailed report and the minimal regex reproduction, they point straight at the cause. I think this is a duplicate of #45558.
The
Prompt.Base64check inpackages/schema/src/prompt.tsuses the exact regex you quoted. On strings longer than a few MB it either overflows the stack (V8) or silently returnsfalse(Bun/JSC). In #45558 this shows up as a 500 onPOST /prompt. Here the attachment was stored first, so the same check now fails each time the message is decoded on reload (Session.MessageDecodeError). The stored data is valid base64, so fixing the regex should make these sessions load again.Possible duplicates and related issues, ordered from most to least likely:
Prompt.Base64regex failing on multi-MB attachments (tracking issue)@-mentioning a large xlsxThe bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
ljx-lll commentedon Oct 13, 2026
Thanks -agreed on the root cause: the backtracking
Prompt.Base64regex inpackages/schema/src/prompt.ts. I'm not claiming a different cause, and the fix in #51272 should resolve it.The reason I filed separately is that the impact is a distinct and more severe failure mode than the attach-time 500 in #45558:
POST /prompt, so the message is never stored and the user can just retry.SessionHistory.load), so the session becomes permanently unloadable:Session.MessageDecodeErroron every drain / server start, and HTTP 500 onGET /api/session/{sessionID}/context. There is no in-app recovery or repair path, so the user loses access to the entire session history, not just the single message.Two requests:
/promptpath does not).I'm fine with it being closed as a duplicate if you consider the impact covered 鈥?I mainly want to flag that the decode/reload path is what breaks existing sessions, and that it currently has no recovery story for affected users.
opencode-agent commentedon Oct 13, 2026
Thanks, and you're right that the impact here is worse. In #45558 the request fails when you send the prompt, so you can just retry. Here the message is saved first, and then the whole session can't be loaded until the check is fixed.
On your two points:
Prompt.Base64schema is used both when a prompt is sent and when a saved message is read back during a session load. The stored data is valid base64, so once the regex is replaced, these sessions should load again without any repair step. The fix is fix(schema): validate canonical base64 without a backtracking regex #51272, which is open and not merged yet. Its tests check the schema directly, including a 20 MB value, which is the same check the reload runs. There is no test yet that reloads a saved session with a large attachment. Whether to add one is up to the maintainers, so it's worth asking for it on fix(schema): validate canonical base64 without a backtracking regex #51272 or attachments: dragging file or pasting file path into input fails session setup (Prompt.Base64 500 on /prompt) #45558.Until the fix ships there's unfortunately no way to recover an affected session from inside the app. To avoid hitting this again in the meantime, don't attach files over ~4 MB (for example, convert PDFs to text first).
Since the cause and the fix are the same, this will still be closed as a duplicate of #45558.
opencode-agent commentedon Oct 14, 2026
Closing this as a duplicate of #45558, since it has the same root cause: the
Prompt.Base64regex fails on multi-MB base64. Thanks for confirming that, and for the clear write-up on how a stored large attachment stops the whole session from loading.The fix is #51272, which is still open. Once a fix like that ships, sessions that already fail to load should open again, because the stored data is valid base64. If you'd like a test that reloads a saved session with a large attachment, please ask on #45558 or #51272, where the maintainers are discussing the fix. If you still see the problem after the fix is released, please open a new issue and link this one.