spice yarrowBOT
That error is the real blocker:
Unrecognized key: "label"underchannels.discord.guilds....channels....
When the config can’t validate, a bunch of CLI commands (including logs) will refuse to run.
Run the auto-repair:
openclaw doctor --fix
That should delete the unknown label key(s) and make the config valid again.
doctor --fix can’t runManually edit:
~/.openclaw/openclaw.jsonlabel: ... line under:channels.discord.guilds.1472150361182830655.channels.1481758360586948698(If you just wanted a human-friendly note, use a JSON5 comment instead — comments are allowed.)
On macOS you don’t use systemctl (that’s Linux). Easiest:
openclaw gateway restart
Or the raw launchd kick:
launchctl kickstart -k gui/$UID/ai.openclaw.gateway
^[[200~... is just a pasted control sequence + you pasted a sentence that included both Linux and mac commands. Just retype the one command you want.compdef not found is zsh completion setup (harmless for running OpenClaw). If you care: make sure your .zshrc runs compinit before sourcing the OpenClaw completion file.If it’s still dead after the fix + restart, paste the output of:
openclaw gateway status
plush needle
🎫 Context Overflow / Session Stability — Ongoing Issue
Environment:
OpenClaw 2026.3.7 (42a1394) on macOS 26.3.1 (arm64, Mac mini M4)
Node v25.6.1
Model: claude-opus-4-6 (150K context) for DMs
25 Discord channels on Sonnet, DMs on Opus
Gateway via LaunchAgent (auto-restart on crash)
The Problem:
During heavy work sessions (building iOS apps, reading logs, running sub-agents), the main DM session hits context limits and triggers compaction. This has happened 7 times in tonight's session alone. When it gets bad enough, the gateway appears to restart entirely — killing the session, losing all logs, and leaving the user staring at silence with no response.
Timeline of tonight's incident:
Session was active with heavy tool use (xcodebuild output, file reads, grep results, sub-agent spawns)
At ~11:05 PM PDT, the agent froze mid-response
Gateway restarted at 11:43 PM (PID 47474 → 2570)
Previous log file was completely lost — no rotation, no .old file, can't post-mortem
After restart, config validation error spammed every ~2 seconds until config was auto-rewritten
What we've tried / current mitigations:
sessionRetention: "2h" (on cron config) — prunes old sessions
historyLimit: 20 was set previously (may have been lost in config rewrites)
channelHealthCheckMinutes: 0 — disabled health checks to reduce overhead
listenerTimeout: 120000 — increased listener timeout
All 25 Discord channels set to Sonnet (cheaper, smaller transcripts)
Only DMs use Opus
All 5 cron jobs on claude-sonnet-4-20250514 with lightContext: true
Manual session resets when channels hit ~80-100K tokens
Sub-agents for heavy coding work (but tool results still land in parent session)
Why it keeps happening:
Even with historyLimit: 20, individual tool call results can be massive. A single xcodebuild archive output is thousands of tokens. A grep across a codebase can be hundreds of lines. 20 messages Ă— heavy tool output = 100K+ tokens fast. The compaction summary itself is also large (preserving build UUIDs, file paths, exact identifiers needed for continuity).
What would help (feature requests):
Log rotation on gateway restart — When the gateway restarts (crash or launchd respawn), the old log file is overwritten. There's no .old or rotated copy. Makes post-mortem impossible. Even keeping the last 1-2 log files would help.
Tool result auto-truncation — Cap tool call results at a configurable max (e.g., 2000 tokens) before they enter the transcript. Build logs, grep output, and file reads are the biggest offenders. The agent can always re-read if it needs more.
Graceful compaction without gateway restart — Currently when compaction can't keep up, the gateway seems to crash/restart. If the compaction could happen in-place (summarize + truncate transcript without killing the process), it would prevent the user-facing freeze.
Config validation: strip unknown keys silently — Tonight an unrecognized "label" key on a channel config caused error spam every ~2 seconds. Could strip unknown keys with a single warning instead of repeating.
Configurable compaction aggressiveness — Option to discard tool results entirely during compaction (keep only the summary/final answer), or to set a target post-compaction size.
Transcript size visibility — A way for the agent to check current transcript size (tokens used / remaining) so it can proactively manage context before hitting limits.
Current session stats (post-compaction):
Context: 92k/150k (62%) — already at 62% right after compaction
Compactions: 7 (in one session tonight)
The 92K is mostly the compaction summary carrying forward exact identifiers, build UUIDs, file paths, and project state needed for continuity. Each compaction preserves this, then new work piles on top, triggering the next compaction in ~20-30 minutes of active use.
spice yarrowBOT
You’re describing two separate pain points that look connected in practice:
Here are the concrete knobs that actually move the needle today.
historyLimit is for channel-provided pending history buffers (mostly groups/channels).
Your Discord DM is the main session transcript on the gateway, so the growth is coming from:
So: you can’t “cap” it with historyLimit the way you were hoping.
Docs reference: https://docs.openclaw.ai/concepts/messages (see “Inbound bodies and history context”)
If the compaction summary must preserve UUIDs/paths/etc, it will naturally become huge and self-perpetuating.
The pattern that works is:
STATE-ios-build.md or STATE.json)That lets you /new (or let auto-compaction happen) without losing critical identifiers, because they live on disk, not in the compaction blob.
Right now you’re paying the price of identifierPolicy: "strict" in a high-output workflow.
Try switching to custom and be much more selective about what to preserve:
{
agents: {
defaults: {
compaction: {
identifierPolicy: "custom",
identifierInstructions:
"Preserve ONLY: current repo path, active branch, the 3 most recent failing file paths, and any IDs explicitly labeled IMPORTANT in STATE-ios-build.md. Do not preserve every UUID/build id.",
// also consider:
// postCompactionSections: [],
},
},
},
}
Config reference: https://docs.openclaw.ai/concepts/compaction and https://docs.openclaw.ai/gateway/configuration-reference#agentsdefaultscompaction
postCompactionSections: [] is worth trying if your AGENTS.md has big sections that keep getting re-injected after each compaction.
Until there’s a first-class “cap tool result tokens” knob for exec, the best fix is: redirect big outputs to files and only return tails/summaries.
Examples:
xcodebuild
xcodebuild ... > /tmp/build.log 2>&1
tail -n 200 /tmp/build.log
ripgrep
rg -n "pattern" . --max-count 50
And as an instruction to the agent: “Never paste full build logs into chat; write to a file and report only errors + last 200 lines.”
This single habit change usually cuts compactions dramatically.
OpenClaw has:
openclaw logs --follow tails): default /tmp/openclaw/openclaw-YYYY-MM-DD.log/tmp gets wiped on reboot)~/.openclaw/logs/gateway.log + gateway.err.log (these can feel “overwritten” depending on how you’re tailing them)If you want logs to survive reboots, set the gateway file log to a persistent path:
{
logging: {
file: "~/.openclaw/logs/openclaw-YYYY-MM-DD.log"
}
}