Summary

Latest openclaw/openclaw main still exposes a transcript-rewrite behavior that re-branches from the first replaced entry and re-appends the remaining suffix. That makes plugin-side transcript GC unsafe when a caller performs repeated rewrites against the same session transcript.

A related config-array delivery/logging discrepancy showed up in the original 2026.4.9 production incident, but I could not reproduce that second part in an isolated 2026.4.9 profile after adding stronger plugin-side diagnostics. I’m including it here as unresolved context, not as a confirmed latest-main repro.

Confirmed On Latest Main

• Local upstream checkout fetched to upstream/main at daeb74920d.
• src/agents/pi-embedded-runner/transcript-rewrite.ts still finds the first rewritten entry and rebuilds the transcript from there, re-appending the remaining suffix after the rewritten segment.
• In the original incident, repeated rewrite-style maintenance produced a ~35 MB workspace-support transcript with ~94.6% duplicate message bytes. The repeated prompt/tool blobs matched suffix replay rather than a clean session join.

Why This Matters

lossless-claw had been using transcript rewrites as part of transcript GC. Even with plugin-side fixes, the host rewrite primitive is still risky because repeated rewrites can duplicate the untouched suffix after the first replaced entry. That creates transcript amplification and follow-on lock/contention behavior when plugins try to clean up large sessions.

Minimal Repro Shape

1. Start from a session transcript with a large trailing suffix.
2. Rewrite one or more entries somewhere before the end of the transcript.
3. Trigger another rewrite/maintenance pass against the same session.
4. Observe the remaining suffix get re-appended from the first rewritten entry forward, producing duplicate prompt/tool blocks.

Additional Context From Validation

• I validated three companion lossless-claw draft PRs against an isolated OpenClaw 2026.4.9 profile:
  • Martian-Engineering/lossless-claw#375
  • Martian-Engineering/lossless-claw#376
  • Martian-Engineering/lossless-claw#377
• In that isolated profile, plugin startup did correctly log the full ignoreSessionPatterns / statelessSessionPatterns arrays from plugin config, and workspace-support stayed at 0 LCM conversations / 0 LCM messages during a real agent:workspace-support:main turn.
• Because of that, I could not reproduce the older config-array drop symptom on the latest isolated run. The production 2026.4.9 logs had previously omitted those arrays even though openclaw.json contained them, so there may still be a separate intermittent config delivery or startup logging gap.

Requested Follow-up

• Make transcript rewrite idempotent for repeated rewrites against the same session suffix, or expose a safer append/update primitive for plugins.
• Add an integration test that performs multiple rewrites against the same transcript and asserts that message count and suffix content stay stable.
• If the config-array discrepancy is still believed possible, add startup tracing for the raw plugin config object handed to plugin registration so it is easier to distinguish config delivery bugs from plugin-side logging bugs.