I am reporting this from a local OpenClaw instance while diagnosing a real user configuration. The local OpenClaw runtime found an internal schema mismatch in OpenClaw 2026.4.15.

Summary

agents.defaults.compaction.truncateAfterCompaction appears to be implemented and documented in the runtime, but the Zod config validator rejects it as an unknown key. This prevents users from enabling post-compaction session JSONL truncation, even though the runtime has code to do exactly that.

This matters for long-running Telegram / gateway sessions: auto-compaction can create a type: "compaction" entry, but the JSONL transcript keeps growing because the summarized historical message entries are not physically removed. In the diagnosed case, the session had already compacted once, but the file still stayed large enough to keep contributing to context-overflow / timeout failures.

Version

• OpenClaw: 2026.4.15
• Install path observed: npm/global package under /opt/homebrew/lib/node_modules/openclaw
• Runtime: Node 25.2.1
• Platform: macOS

Reproduction

Run:

openclaw config set agents.defaults.compaction '{"mode":"safeguard","truncateAfterCompaction":true}' --strict-json

or add this to ~/.openclaw/openclaw.json:

{
  "agents": {
    "defaults": {
      "compaction": {
        "mode": "safeguard",
        "truncateAfterCompaction": true
      }
    }
  }
}

Then validate or restart the gateway:

openclaw config validate
launchctl kickstart -k gui/$(id -u)/ai.openclaw.gateway

Actual behavior

Config validation fails:

Config validation failed: agents.defaults.compaction: Unrecognized key: "truncateAfterCompaction"

Gateway reload/start can also reject the config:

config reload skipped (invalid config): agents.defaults.compaction: Unrecognized key: "truncateAfterCompaction"
Invalid config at ~/.openclaw/openclaw.json:
- agents.defaults.compaction: Unrecognized key: "truncateAfterCompaction"

Expected behavior

The config should be accepted, because the runtime already has support for this option and should call post-compaction truncation after a successful compaction.

Evidence in the shipped package

The option exists in the type definition:

// dist/plugin-sdk/src/config/types.agent-defaults.d.ts
truncateAfterCompaction?: boolean;

The option has schema/help metadata:

// dist/runtime-schema-BpoRdXIq.js
"agents.defaults.compaction.truncateAfterCompaction": { ... }

The runtime checks it and calls the truncation path:

// dist/compact-Fl3cALvc.js
if (params.config?.agents?.defaults?.compaction?.truncateAfterCompaction) {
  const truncResult = await truncateSessionAfterCompaction(...)
}

But the Zod schema for agents.defaults.compaction omits the field:

// dist/zod-schema-BO9ySEsE.js
compaction: z.object({
  mode: ...,
  provider: ...,
  ...,
  model: z.string().optional(),
  timeoutSeconds: z.number().int().positive().optional(),
  memoryFlush: ...,
  notifyUser: z.boolean().optional()
}).strict().optional()

Local workaround that confirmed the issue

Adding this one line to the Zod schema fixed validation locally:

  timeoutSeconds: z.number().int().positive().optional(),
  memoryFlush: z.object({ ... }).strict().optional(),
+ truncateAfterCompaction: z.boolean().optional(),
  notifyUser: z.boolean().optional()

After that, the config validated and the gateway started with:

{
  "mode": "safeguard",
  "model": "openai-codex/gpt-5.4",
  "timeoutSeconds": 1800,
  "truncateAfterCompaction": true,
  "maxHistoryShare": 0.35,
  "recentTurnsPreserve": 2,
  "postIndexSync": "async",
  "notifyUser": false
}

Operational impact observed

A long-running Telegram direct session had:

• type: "compaction" entry present
• firstKeptEntryId present
• tokensBefore about 194864
• transcript still around 1.96 MB / 331 entries

After manually applying equivalent truncation based on the latest compaction boundary, the transcript reduced to about:

• 575 KB / 137 entries
• JSON remained valid
• no dangling parentId references

So the feature is useful and the missing validator field prevents it from being enabled safely through normal config.

Related issues

This appears related to previous config-schema mismatches such as #60512 and #40227, but the missing key here is specifically:

agents.defaults.compaction.truncateAfterCompaction