[Feature] Auto-tune or warn on session.parentForkMaxTokens instead of silent skip

[Hugo0]

Problem

session.parentForkMaxTokens defaults to 100000. When a parent session exceeds this, session-init silently skips the fork with a WARN-level log line:

[session-init] skipping parent fork (parent too large):
  parentKey=agent:main:discord:channel:1234
  → sessionKey=agent:main:discord:channel:5678
  parentTokens=154551
  maxTokens=100000

The child session starts with no context from the parent. For a Discord channel used as the agent's "home" channel, this manifests as the agent suddenly forgetting recent conversations at seemingly random intervals.

Observed in production

Today on 2026.4.8: our #chat parent session grew to 154,551 tokens vs the 100k cap. 4 child threads opened over a morning all started cold. Users experienced the agent as "amnesiac" — forgetting things it was told 30 min ago.

Current workaround

Raised session.parentForkMaxTokens to 200000. Opus has ~1M context so 200k is still conservative, but this is a manual tuning exercise per deployment. When the session grows past 200k we'll hit the same silent fork skip again.

Proposed solutions (pick one or more)

1. Auto-compact the parent before forking — if parentTokens > maxTokens, trigger a compaction pass on the parent session before forking, instead of silently skipping. This feels like the right default given the new pluggable compaction provider (feat: add pluggable compaction provider registry #56224) and memoryFlush (2026.4.7).

2. Promote the WARN to a visible signal — post a one-time message to the originating channel ("⚠️ context window full, starting fresh — previous conversations not carried over") so users understand why the agent forgot things. Currently only logged.

3. Auto-scale the default — default maxTokens to e.g. min(500_000, modelContextWindow × 0.25) instead of the static 100_000. For Opus/Sonnet/GPT-5 the 100k default is now extremely conservative.

Related

• feat: add pluggable compaction provider registry #56224 — pluggable compaction provider (could be wired into fork path)
• feat(gateway): add compaction checkpoints #62146 — persisted compaction checkpoints (gives a safe rollback point)
• Session hangs indefinitely when compaction times out, causing repeated duplicate message sends #43661 — session hangs on compaction timeout (relevant if we auto-compact)

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve.

Summary
Keep open. Current main still starts oversized parent-fork channel/thread children with isolated context after a log-only skip; the requested visible warning, pre-fork compaction, and model-aware cap sizing are not implemented.

Reproducibility: yes. Source and tests provide a high-confidence path: create a parent session above 100,000 tokens, initialize a child with ParentSessionKey, and current main marks the child forked with fresh isolated context while only logging the skip on the channel/thread path.

Next step
The warning slice is narrow and source-backed; a worker should not attempt automatic compaction or cap-sizing policy.

Review details

Best possible solution:

Add a session-owned, deduped visible warning when channel/thread parent inheritance is skipped, leaving automatic parent compaction and model-derived cap sizing for separate design work.

Do we have a high-confidence way to reproduce the issue?

Yes. Source and tests provide a high-confidence path: create a parent session above 100,000 tokens, initialize a child with ParentSessionKey, and current main marks the child forked with fresh isolated context while only logging the skip on the channel/thread path.

Is this the best way to solve the issue?

Yes for the narrow warning slice. A deduped visible warning is the smallest maintainable next step; auto-compaction and dynamic cap sizing are broader compaction/model-budget policy changes that should not be bundled into this repair.

Acceptance criteria:

• node scripts/run-vitest.mjs src/auto-reply/reply/session.test.ts src/agents/subagent-spawn.context.test.ts
• node scripts/run-vitest.mjs src/auto-reply/reply/get-reply.test.ts src/auto-reply/reply/get-reply-run*.test.ts src/auto-reply/reply/agent-runner.runreplyagent.e2e.test.ts
• node scripts/crabbox-wrapper.mjs run --runner blacksmith-4vcpu-ubuntu-2404 --shell -- "pnpm exec oxfmt --check --threads=1 src/auto-reply/reply/session.ts src/auto-reply/reply/session-fork.ts src/auto-reply/reply/session.test.ts src/agents/subagent-spawn.context.test.ts docs/reference/session-management-compaction.md CHANGELOG.md && pnpm check:changed"

What I checked:

• Live issue state: The issue is still open, has no protected labels, and the only existing review comment also kept it open for the same unresolved parent-fork behavior.
• Static skip threshold remains: Current main still uses DEFAULT_PARENT_FORK_MAX_TOKENS = 100,000, and resolveParentForkDecision returns status "skip" with reason "parent-too-large" when the parent token count exceeds that cap. (src/auto-reply/reply/session-fork.ts:9, 99dfb8291f1c)
• Channel/thread skip is log-only: initSessionState logs the oversized parent fork skip and marks forkedFromParent, but it does not deliver forkDecision.message to the originating channel and does not compact before starting the child isolated. (src/auto-reply/reply/session.ts:726, 99dfb8291f1c)
• Current tests lock in isolated fallback: The session test creates an oversized parent, initializes a child with ParentSessionKey, and asserts the child is marked forked while using a fresh session id and file instead of the parent transcript. (src/auto-reply/reply/session.test.ts:516, 99dfb8291f1c)
• Subagent path already has a visible note: The subagent fork path records forkDecision.message for oversized parent skips and appends it to the accepted response, showing reusable warning text exists but is not wired into channel session-init. (src/agents/subagent-spawn.ts:386, 99dfb8291f1c)
• Docs describe isolated fallback: The public session-management docs say oversized parent branches start children with isolated context and that legacy session.parentForkMaxTokens is removed, but they do not describe a visible warning or automatic pre-fork compaction. Public docs: docs/reference/session-management-compaction.md. (docs/reference/session-management-compaction.md:162, 99dfb8291f1c)

Likely related people:

• markshields-tl: Authored the earlier parent-fork overflow fix that introduced the 100,000-token skip/fresh-start behavior for oversized parent transcripts. (role: introduced predecessor behavior; confidence: high; commits: e9e61ab7cf6e; files: src/auto-reply/reply/session.ts, src/auto-reply/reply/session.test.ts, src/auto-reply/reply/agent-runner-execution.ts)
• jalehman: Authored the parent-fork overflow guard hardening that made stale or missing parent token metadata fall back to transcript estimation around the same decision path. (role: adjacent parent-fork hardening contributor; confidence: high; commits: 4570c9165125, 92d0e7dbe693; files: src/auto-reply/reply/session-fork.ts, src/auto-reply/reply/session.ts, src/auto-reply/reply/session.test.ts)
• steipete: Recent commits centralized the parent-fork policy for sessions/subagents and removed the legacy parentForkMaxTokens config knob now referenced by this issue. (role: recent area contributor; confidence: high; commits: 3a4d9ee61daf, b3458307f37b; files: src/auto-reply/reply/session-fork.ts, src/auto-reply/reply/session.ts, src/agents/subagent-spawn.ts)
• DhruvBhatia0: Authored the merged compaction provider registry cited by the issue as possible infrastructure for a broader auto-compact-before-fork design. (role: adjacent compaction contributor; confidence: medium; commits: 12331f04631f; files: src/plugins/compaction-provider.ts, src/agents/pi-hooks/compaction-safeguard.ts, docs/reference/session-management-compaction.md)
• scoootscooob: Authored the merged compaction checkpoint/recovery work cited by the issue as relevant if maintainers later choose automatic parent compaction. (role: adjacent recovery contributor; confidence: medium; commits: f4fcaa09a358; files: src/gateway/session-compaction-checkpoints.ts, src/agents/pi-embedded-runner/compact.ts, ui/src/ui/views/sessions.ts)

Remaining risk / open question:

• Automatic parent compaction should stay out of a narrow repair while Session hangs indefinitely when compaction times out, causing repeated duplicate message sends #43661 still tracks compaction timeout, retry, and duplicate-send risk.
• A visible channel warning needs session-owned dedupe or rate limiting so active channels do not receive repeated notices for the same oversized parent.
• Model-derived cap sizing touches broader model-budget policy and should remain separate from the minimal warning path.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 99dfb8291f1c.