Session too large to share: ${sealed.byteLength} bytes seale

Error message

Session too large to share: ${sealed.byteLength} bytes sealed exceeds the ${maxBytes} byte limit

What it means

sealToFit encrypts a session for sharing and progressively shrinks it (strip images, cap long strings, halve the entry list down to a floor of 4 entries) until the AES-GCM sealed blob fits maxBytes. If even the minimal payload (at most 4 entries, truncated strings, no images) still encrypts larger than maxBytes, the function gives up and throws this error rather than produce an undeliverable share.

Source

Thrown at packages/coding-agent/src/export/share.ts:548

	const working = structuredClone(data);
	stripImagePayloads(working);
	sealed = await sealSessionData(key, working);
	if (sealed.byteLength <= maxBytes) return { sealed, truncated: true };

	for (const cap of TEXT_CAPS) {
		capLongStrings(working, cap);
		sealed = await sealSessionData(key, working);
		if (sealed.byteLength <= maxBytes) return { sealed, truncated: true };
	}

	// Last resort: drop oldest entries (orphaned children render as roots).
	while (working.entries.length > 4) {
		working.entries = working.entries.slice(Math.ceil(working.entries.length / 2));
		sealed = await sealSessionData(key, working);
		if (sealed.byteLength <= maxBytes) return { sealed, truncated: true };
	}

	throw new Error(`Session too large to share: ${sealed.byteLength} bytes sealed exceeds the ${maxBytes} byte limit`);
}

/** `[12B IV][AES-256-GCM(gzip(JSON))]` — decrypted and gunzipped by share-loader.js. */
async function sealSessionData(key: CryptoKey, data: SessionData): Promise<Uint8Array<ArrayBuffer>> {
	const compressed = Bun.gzipSync(new TextEncoder().encode(JSON.stringify(data)));
	const iv = new Uint8Array(IV_LENGTH);
	crypto.getRandomValues(iv);
	const ciphertext = new Uint8Array(await crypto.subtle.encrypt({ name: "AES-GCM", iv }, key, compressed));
	const out = new Uint8Array(IV_LENGTH + ciphertext.byteLength);
	out.set(iv, 0);
	out.set(ciphertext, IV_LENGTH);
	return out;
}

function isRecord(value: unknown): value is Record<string, unknown> {
	return typeof value === "object" && value !== null;
}

View on GitHub (pinned to 9690622007)

Solutions

Reduce the session content before sharing: start a fresh session or delete/clear the largest entries (huge tool outputs, pasted files) and retry the share.
Raise or check the byte budget: if you control the call site, pass a larger maxBytes to sealToFit / configure the share server limit appropriately.
Re-run the share after compacting: the error message reports the actual sealed size vs the limit, so trim content until it fits (e.g. remove the remaining oversized entries).
If the target is a gist, use the server share path or vice versa — different hosts have different limits.

Example fix

// before
await share.forServer(session, { maxBytes: 512 * 1024 }); // session has 4 x 500KB pasted logs
// after
// trim the session first (drop huge tool outputs), or raise the budget:
await share.forServer(session, { maxBytes: 8 * 1024 * 1024 });

Defensive patterns

Strategy: validation

Validate before calling

// Rough pre-check: estimate JSON size before sharing
const approx = new TextEncoder().encode(JSON.stringify(sessionData)).byteLength;
if (approx > maxBytes) {
  // trim entries/tool outputs first, or pick a host with a bigger limit
}

Try / catch

try {
  const { sealed, truncated } = await sealToFit(key, data, maxBytes);
} catch (err) {
  if (err instanceof Error && err.message.startsWith('Session too large to share')) {
    // fall back to local export or prompt user to trim the session
  } else throw err;
}

Prevention

Prune large tool outputs and pasted files from sessions before sharing
Check session size before share and warn the user early
Know each host's byte limit (gist vs share server) and choose accordingly
Keep maxBytes budgets in one config place so they can be raised

When it happens

Trigger: Calling forGist/forServer/sealToFit on a session whose remaining content exceeds the share byte budget even after image stripping, string capping, and entry halving to the 4-entry floor — e.g. 4 entries each containing megabytes of pasted text against a small maxBytes budget.

Common situations: Sharing an extremely long session with giant tool outputs or pasted logs; sharing over a host that enforces a tight upload limit (GitHub Gist limits, a self-hosted share server with a small body cap); running an older share client against a server whose limit was lowered.

Related errors

AI-assisted analysis of can1357/oh-my-pi@9690622007 (2026-08-31). Data as JSON: /api/errors/450f049523e5a4bd. Report an issue: GitHub.