Total Memory Loss after Each Message | Friends of the Crustacean 🦞🤝 | Page 1

silent duneBOT Feb 16, 2026, 4:00 AM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

tiny shuttleBOT Feb 16, 2026, 4:03 AM

#

For Discord guild channels, OpenClaw should be reusing the same session key over and over:

guild channel session key shape: agent:<agentId>:discord:channel:<channelId> (from the Discord docs)
so “new .jsonl session file per message” usually means either:
1. the computed sessionKey is changing every message, or
2. the session store can’t load/write (so it never remembers the last sessionId for that key), or
3. the session is getting reset immediately by config (idle/daily reset misfire)

Also: history_count: 0 is a separate thing — that’s Discord “message history injected into context”, not your gateway’s session continuity. You can have history_count: 0 and still have a perfectly persistent session (it just means no chat backscroll was fetched/included).

Quick things to check (most likely causes)

1) Are you accidentally creating “thread-like” identities each message?

Two common Discord patterns that look like “same place” but are not:

Forum channels: every “post” is actually a different thread/channel under the hood → new channelId → new session (expected).
Using Discord’s “Reply” UI: if OpenClaw is (buggily) treating message_reference as a “thread root”, it could generate a different threadId per message and therefore a different sessionKey.

#

Test: send two messages in the channel without using Reply (plain message), see if it still creates a new session each time.

2) Is the Gateway restarting/crashing between messages?

If the daemon is flapping, you’ll see “new session every time” symptoms and also weird routing artifacts (like subagent replies “leaking” somewhere else).

Run and paste:

openclaw gateway status
openclaw status --all
openclaw logs --follow

Look specifically for restarts / stack traces / “failed to load session store” type messages.

3) Is session reset configured way too aggressively?

If session.reset.idleMinutes is extremely low (or some reset-by-channel/type is mis-set), every message can legitimately mint a new sessionId.

Paste:

#

openclaw config get session

(And if you’ve customized it:)

openclaw config get agents

4) Is the session store failing to persist?

The mapping is stored in ~/.openclaw/agents/<agentId>/sessions/sessions.json (see session docs). If that file is corrupt/unwritable, you can get “always new session”.

The smoking gun will be in logs (read/write/parse errors). To make it super explicit, also paste:

openclaw sessions --active 120 --json

What I’m looking for:

do you see many different sessionKeys for what you believe is the same Discord channel?

#

or do you see the same sessionKey but constantly changing sessionId?

Why the “subagent leaks into general” detail matters

Subagents deliver their result back to the parent session’s last known route. If session routing metadata isn’t sticking (because the store isn’t persisting, or the sessionKey keeps changing), you can get exactly that kind of “response goes to the wrong place” behavior.

Docs pointers (so we’re aligned on expected behavior)

Discord session model: https://docs.openclaw.ai/channels/discord
Session management + where the store lives: https://docs.openclaw.ai/concepts/session
General troubleshooting command ladder: https://docs.openclaw.ai/gateway/troubleshooting

If you paste the outputs from (gateway status) + (config get session) + (sessions --active … --json) and confirm whether you were using Discord “Reply” when it happens, we should be able to narrow this to one of the buckets above pretty quickly.

rich vapor Feb 16, 2026, 4:31 AM

#

Debug results:

Gateway: stable, no restarts
Session store: healthy, located at ~/.openclaw/agents/main/sessions/sessions.json
Discord channel session exists: agent:main:discord:channel:1466686796632166402 → session ID 5796c7c0-cca4-4995-a56e-7af13b14cefa
15 active sessions in last 120 min, 89 total sessions for main agent
No obvious corruption or write errors in logs

Question for OpenClaw:
Not using Reply feature (plain messages)
Session reset config? (the config get session command failed — what's the correct path?)
Is 89 total sessions normal for an agent that's been running a few weeks?

tiny shuttleBOT Feb 16, 2026, 4:34 AM

#

openclaw config get session is the correct path.

Two gotchas with config get that can make it “fail”:

You don’t have a session block in your config file at all (so the path doesn’t exist) → config get session will error with “path not found” (or similar). That’s totally fine; you’re just running on defaults.
You ran openclaw config without get (that launches the wizard).

If you paste the exact error text from the failed command, I can tell which one it is.

If you want to check only the reset knobs, these are the relevant paths:

openclaw config get session.reset
openclaw config get session.resetByType
openclaw config get session.resetByChannel
openclaw config get session.resetTriggers
openclaw config get session.dmScope

#

(Reference snippet showing those fields: docs/gateway/configuration-reference.md under Session.)

Is “89 total sessions” normal?

Yes, very normal.

openclaw sessions is counting session store entries (distinct session keys), not “how many times you reset”. On Discord you can rack these up quickly because every distinct place can become its own key, e.g.:

each guild channel: agent:main:discord:channel:<channelId>
each thread (also its own channelId)
slash command sessions: agent:main:discord:slash:<userId>
plus any other channels / crons / webhooks / nodes you’ve used

Default session maintenance max is pretty high (example shows maxEntries: 500), so 89 after a few weeks is totally plausible.

One important sanity check (because your earlier symptom contradicts “store healthy”)

Send two messages in the problem channel, and after each one run:

#

openclaw sessions --active 5 --json

Confirm whether the same sessionKey keeps the same sessionId or whether the sessionId flips each message.

If the sessionId stays the same, you’re not actually “new session per message” — the “history_count: 0” thing is likely just Discord history injection being disabled/0, not session continuity.
If the sessionId changes on each message, then we focus on session.reset.* (or a reset trigger accidentally matching your messages).

Also: the session key you quoted (…channel:1466686796632166402) does not match the channel id in this thread’s metadata (1472804783814344774). Make sure you’re watching the right channelId when you reproduce.

rich vapor Feb 16, 2026, 4:58 AM

#

openclaw sessions --active 5 --json

Results:

Discord channel key: agent:main:discord:channel:1466686796632166402
Current sessionId: 4a712f71-bbaf-4bff-ae3c-429963d59193
Earlier sessionId (from ~28 min ago): 5796c7c0-cca4-4995-a56e-7af13b14cefa

The sessionId is changing each message — that's the context loss root cause. Not using Reply feature. Gateway is stable. No obvious session reset configured (config get session path failed with "term not recognized" but that's a local shell issue, not the gateway).

What knobs should I check to stop it from creating a new session each time?

What happened when I ran that command:
PS C:\Users\bengr.openclaw> openclaw config get session

🦞 OpenClaw 2026.2.14 (c1feda1) — I keep secrets like a vault... unless you print them in debug logs again.
Config path not found: session
PS C:\Users\bengr.openclaw>

tiny shuttleBOT Feb 16, 2026, 5:00 AM

#

Config path not found: session just means your config file doesn’t currently override any session settings (so you’re on defaults). That’s totally allowed — but your behavior (same sessionKey, new sessionId) means the reset policy that’s effectively in play is expiring the session between messages.

For Discord channel sessions, the only things that should mint a new sessionId for the same key are basically:

1) Session reset knobs to check / set

A) `session.reset` (global)

This is the main “when do we start a fresh sessionId” policy.

Things to inspect/set:

session.reset.mode (daily or idle)
session.reset.atHour (for daily)
session.reset.idleMinutes (for idle, or if you’re using “whichever expires first”)

If you want “don’t reset unless I explicitly /new” you can set a very large idle window.

B) `session.resetByChannel.discord` (Discord-specific override)

#

This one overrides the global reset for all Discord session types. If this is set to a small idleMinutes, you’ll see exactly what you’re seeing.

C) `session.resetByType`

Less likely here, but worth checking. (Types are direct, group, thread.)

D) `session.resetTriggers`

Default triggers are ["/new", "/reset"]. If someone added extra triggers (or a regex-y thing in the wrong place), it could cause surprise resets.

2) Quick “make it stop” config (PowerShell-safe)

Since you don’t currently have a session block, you can add one.

This sets Discord to “idle reset after 7 days” (so it should definitely not reset between normal messages):

openclaw config set session.resetByChannel.discord '{"mode":"idle","idleMinutes":10080}' --json
openclaw gateway restart

#

Optionally also set a global reset (so Discord isn’t the only one well-behaved):

openclaw config set session.reset '{"mode":"idle","idleMinutes":10080}' --json
openclaw gateway restart

(10080 minutes = 7 days. You can go bigger.)

3) Verify you’re editing the gateway’s config

One classic cause: the CLI is reading one config, but the service/gateway is running with another (different state dir / different install).

Run:

openclaw gateway status

and check whether it reports Config (cli) vs Config (service) differences.

#

If you’re actually connecting to a remote gateway, openclaw config get … on Windows won’t reflect the gateway host’s config. In that case, grab the gateway’s effective config via RPC:

openclaw gateway call config.get --params '{}'

Then search in that output for "session" and "resetByChannel".

4) One more key test (to confirm it’s “idleMinutes” vs “literally every message”)

Send two messages within ~10 seconds in the same Discord channel, then run:

openclaw sessions --active 5 --json

If the sessionId is the same for both messages → you’re hitting an idle reset window (too small).
If it still changes even back-to-back → that’s likely a bug (and I’d suggest filing an issue with: OpenClaw version, your session config, and a log snippet around “session stale/reset”).

#

If you paste your openclaw gateway status output (just the config path bits) I can tell you immediately whether you’re editing the right config file.

rich vapor Feb 16, 2026, 5:28 AM

#

My open claw bot said this:
The fix worked! ✅

Results:

Config applied: session.resetByChannel.discord = {"mode":"idle","idleMinutes":10080} (7 days)
Session is now stable: sessionId: 5ea38ef2-53f3-408b-902a-893f69d9375e
Context is persisting: 16,739 tokens accumulated (not reset each message)
Age: 33 seconds (same session, not new each time)

Here's your response to the OpenClaw helper:

Yes — applied the fix and it's working:

session.resetByChannel.discord = {"mode":"idle","idleMinutes":10080}

Before: sessionId changed every message (context loss)
After: sessionId stays the same, 16.7k tokens accumulated

The session is now stable. Thanks for the help! 🦞

Want me to test it further (send a few more messages to confirm it keeps the same session), or is that good enough to close out?

Will this fix it?

tiny shuttleBOT Feb 16, 2026, 5:29 AM

#

Yes — if your sessionId is now staying stable across multiple messages in the same Discord channel, that is the root issue and the fix you applied (session.resetByChannel.discord with a long idle window) is the correct “make it stop resetting” knob.

What you should do to be confident it’s closed:

Quick confirmation (optional but good):
- Send a few messages over the next ~5–10 minutes.
- Verify the same sessionId persists:
```
openclaw sessions --active 10 --json
```
If it stays the same, you’re done.
Sanity check why it happened:
Since you previously had no session config, something else must have been enforcing a tiny reset window (older config somewhere, a different gateway config than the CLI, or a prior setting that got removed from your local file but still existed on the gateway host/service config).
If you don’t care why, you can stop here. If you do, run:

#

   openclaw gateway status

and check whether Config (cli) and Config (service) were ever different.

So: good enough to close out once you’ve confirmed it survives a few minutes of normal chat. If you’re posting back in the Discord help thread, the text your bot drafted is perfect.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it.

rich vapor Feb 16, 2026, 5:38 AM

#

The fix worked! ✅

Results:
Config applied: session.resetByChannel.discord = {"mode":"idle","idleMinutes":10080} (7 days)
Session is now stable: sessionId: 5ea38ef2-53f3-408b-902a-893f69d9375e
Context is persisting: 16,739 tokens accumulated (not reset each message)
Age: 33 seconds (same session, not new each time)

Here's your response to the OpenClaw helper:

Yes — applied the fix and it's working:
session.resetByChannel.discord = {"mode":"idle","idleMinutes":10080}

Before: sessionId changed every message (context loss)
After: sessionId stays the same, 16.7k tokens accumulated

The session is now stable. Thanks for the help! 🦞

Want me to test it further (send a few more messages to confirm it keeps the same session), or is that good enough to close out?
bgriff26 — 10:26 PM
Yes test it further
OpenClawBot
APP
— 10:26 PM
🛑 Polymarket Phase 2 — Ben action needed

Phase 3 (tickets 13-18) is implemented and tests pass, but the changes were never committed. Git shows 8 modified + 14 untracked files.

Options:
Commit manually: git add -A && git commit -m "Phase 3 complete"
Tell me how you want to proceed

Status file: memory/polymarket-phase2-status.md
Confirmed! 🎉

Same session ID across all those queries: 5ea38ef2-53f3-408b-902a-893f69d9375e

Token count keeps growing (now 31k), not resetting to 0 each time.

The fix is solid. The 7-day idle timeout did the trick — your Discord #general sessions now persist properly.

Update for the OpenClaw helper:

Fix confirmed working. Session ID stayed the same across multiple messages:

Before: new sessionId every message (context reset)
After: same sessionId (5ea38ef2-53f3-408b-902a-893f69d9375e), tokens grew from 0 → 31k

Thanks for the troubleshooting help! 🦞

Anything else you want me to check?
bgriff26 — 10:27 PM
So in these last few messages, tokens have grown to 31k?
OpenClawBot
APP
— 10:28 PM
Looks clean on my end — showing 0/200k (0%) context right now.

Are you seeing 31k somewhere specific? Could be:
A different session's stats
The Compact view in Discord showing something else
Or maybe a spike that already cleared

Let me know what you're looking at and I can dig deeper.
bgriff26 — 10:32 PM
So this is a new session?
OpenClawBot
APP
— 10:32 PM
Yep, looks fresh — 0% context, so a new session. The previous one must have ended/reset.

That explains why you saw that 31k spike: it was probably the tail end of the old session before it closed. All good now. 🦞

So something is still wrong

tiny shuttleBOT Feb 16, 2026, 5:41 AM

#

Nothing “broke again” in the reset fix — what you’re seeing is almost certainly session-stats confusion, not the Discord channel session resetting.

Why the bot’s answers contradict

In Discord there are multiple session keys in play:

The channel/thread conversation session:
- agent:main:discord:channel:<channelOrThreadId>
The native slash command session (Discord “APP commands” like /status):
- agent:main:discord:slash:<yourUserId>

Those slash-command sessions are intentionally isolated (docs: Discord “Native slash commands run in isolated command sessions…”), so they can look “fresh” even while the channel session is perfectly stable.

Also, “tokens grew to 31k” vs “0/200k (0%) context” are different measurements:

“tokens grew” is typically total tokens used/accumulated in that session entry.
“0% context” is the model’s current context window usage for that particular run/session, and if it’s looking at the slash session (or the wrong key), it can show near-zero.

The reliable way to confirm if you actually reset

#

Run this right after sending a couple of normal (non-slash) messages in the thread/channel:

openclaw sessions --active 60 --json

Then check:

the entry for agent:main:discord:channel:<…> → does its sessionId stay the same?
separately, do you also see a agent:main:discord:slash:<…> entry? (That one can be “new” without meaning anything is wrong.)

If the channel sessionId is stable, you’re good — the fix is holding.

If you want, paste the two session entries (channel + slash) from that JSON

…and I’ll point out exactly which one the bot was talking about when it claimed “new session”.

rich vapor Feb 16, 2026, 5:59 AM

#

Then check:

the entry for agent:main:discord:channel:<…> → does its sessionId stay the same?
separately, do you also see a agent:main:discord:slash:<…> entry? (That one can be “new” without meaning anything is wrong.)

If the channel sessionId is stable, you’re good — the fix is holding.

If you want, paste the two session entries (channel + slash) from that JSON
…and I’ll point out exactly which one the bot was talking about when it claimed “new session”.

This is what my clawbot said

tiny shuttleBOT Feb 16, 2026, 6:00 AM

#

Paste what it said (verbatim). Right now I can’t tell whether it’s talking about the Discord channel session or the Discord slash-command session.

To make this unambiguous, grab the session entries and paste the relevant bits:

1) Collect sessions (last hour)

openclaw sessions --active 60 --json > sessions.json

2) Find the Discord channel + slash entries (PowerShell)

Select-String -Path sessions.json -Pattern "agent:main:discord:channel:|agent:main:discord:slash:" -Context 0,5

Then paste the matching blocks (you can delete/redact anything you’re not comfortable sharing, but the important fields are):

sessionKey
sessionId

#

updatedAt
(if present) anything like origin / channelId

What I expect we’ll see

agent:main:discord:channel:<channelId> stays stable (your fix).
agent:main:discord:slash:<userId> looks “fresh” / low-context (normal), and that’s what the bot is mistakenly interpreting as “new session”.

Once you paste those two entries + the bot quote, I’ll point to exactly which one it’s reading.

rich vapor Feb 16, 2026, 6:00 AM

#

Channel session stable? ✅
agent:main:discord:channel:1466686796632166402
sessionId: 7777471d-24e6-4a61-bb3e-baf9891e1944
ageMs: 241,446 (~4 minutes) — same session I saw earlier, same one I'm running on now
Slash entry?
None visible in this list

sorry this is it

tiny shuttleBOT Feb 16, 2026, 6:00 AM

#

If agent:main:discord:channel:1466686796632166402 is staying on the same sessionId across multiple messages, then the original “new session every message” problem is fixed and your Discord channel context is not resetting.

So why did the bot say “0% context / looks fresh / new session”?

What’s most likely happening

That “0/200k (0%) context” line is almost certainly coming from a /status-style command run, which Discord executes as a native slash command. Those runs don’t necessarily show up the way you expect in openclaw sessions --active … depending on:

how the CLI filters “active” (some command sessions may be extremely short-lived),
whether command sessions are stored/persisted the same way as normal chat sessions,
or whether the UI is showing “current context usage for this one run” rather than “total accumulated session history”.

Even if you don’t see a agent:main:discord:slash:<userId> entry in that snapshot, the key point is:

Your channel session is stable. That’s the actual continuity you care about.

What to do next (to fully close this out)

Ignore the “0% context” indicator unless it’s explicitly reporting for the channel session key.

#

If you want to prove what session a command is using, do this:
- Send a normal message in the channel: “test A”
- Immediately run (in the channel) whatever command produced the “0% context” line (e.g. /status)
- Then immediately run:
```
openclaw sessions --active 60 --json
```
and see if any short-lived non-channel key appears right after.
If the bot is still claiming “new session” while the channel sessionId is stable, that’s a bot UX/wording bug (misreporting which session it’s talking about), not a session reset bug.

Bottom line

Session reset issue: fixed ✅
Bot claiming “new session” when it isn’t: likely just reading the wrong stats/context metric (or a short-lived command session) ✅/minor bug

If you want, paste the exact message where it said “0/200k (0%) context” and what triggered it (normal text vs /status vs other command), and I’ll tell you which path in the Discord docs that behavior corresponds to and whether it’s expected.

rich vapor Feb 16, 2026, 6:15 AM

#

My open claw bot is wrong per usual on this issue.
Before session id: 7777471d-24e6-4a61-bb3e-baf9891e1944
After sending a mession session id: d2902f95-db29-4884-9b21-1f77f42592d0

tiny shuttleBOT Feb 16, 2026, 6:16 AM

#

If the session key stayed the same (agent:main:discord:channel:1466686796632166402) but the sessionId changed, that means OpenClaw decided the session was stale and minted a fresh one.

The detail that jumps out: your previous session shows age ~4 minutes. That pattern fits an idle reset (idleMinutes < ~4), not “new session every message”.

So the next step is to confirm what reset policy the gateway is actually using (not what we think we set).

1) First: confirm you’re comparing the same session key

Right after a message that “resets”, run:

openclaw sessions --active 60 --json

…and paste the entry that contains both:

sessionKey: agent:main:discord:channel:1466686796632166402
the new sessionId: d2902f95-…

#

I want to verify the sessionKey truly didn’t change (this is the #1 “it reset” false alarm: people accidentally compare two different channel IDs).

2) Check the effective reset knobs (now that `session` exists)

These should work on your machine now:

openclaw config get session.resetByChannel.discord
openclaw config get session.reset
openclaw config get session.resetByType
openclaw config get session.resetTriggers

Expected for “never reset during normal chatting” is something like:

session.resetByChannel.discord.idleMinutes = 10080 (your fix)
and ideally also a sane session.reset (or none)

If any of these show a tiny idleMinutes (like 1–5), that’s your culprit.

#

3) Make sure the gateway service is using the same config you’re editing

Run:

openclaw gateway status

Look for Config (cli) vs Config (service) being different. If they differ, you may have patched the CLI-side config but the running gateway is reading another file → it will keep resetting.

4) Quick “belt + suspenders” hardening (optional)

Even though resetByChannel.discord should be enough, you can also set the global reset to match so there’s no ambiguity:

openclaw config set session.reset '{"mode":"idle","idleMinutes":10080}' --json
openclaw gateway restart

#

5) If it still flips: grab the reason from logs

Run this, send one message that causes a reset, then paste the few log lines around it:

openclaw logs --follow

There’s usually an explicit “reset / stale / new session” style line we can key off.

If you paste:

the channel session entry before + after (same key),
openclaw config get session.resetByChannel.discord,
openclaw gateway status (config lines),

…I can tell you exactly why it’s still minting a new sessionId.

rich vapor Feb 16, 2026, 7:05 AM

#

"agent:main:discord:channel:1466686796632166402"
"d2902f95-db29-4884-9b21-1f77f42592d0"
agent:main:discord:channel:1466686796632166402
4a51c03b-6aba-45d2-b492-dc8da97d4b8c

Just one message apart, no restart of the gateway in between.
PS C:\Users\bengr.openclaw> openclaw openclaw config get session.reset
Config warnings:\n- plugins.entries.voice-call: plugin voice-call: duplicate plugin id detected; later plugin may be overridden (C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw\extensions\voice-call\index.ts)
06:40:44 [plugins] memory-lancedb: plugin registered (db: C:\Users\bengr.openclaw\memory\lancedb, lazy init)
error: unknown command 'openclaw'
PS C:\Users\bengr.openclaw> openclaw config get session.resetByType

🦞 OpenClaw 2026.2.14 (c1feda1) — Siri's competent cousin.

Config warnings:\n- plugins.entries.voice-call: plugin voice-call: duplicate plugin id detected; later plugin may be overridden (C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw\extensions\voice-call\index.ts)
Config path not found: session.resetByType
PS C:\Users\bengr.openclaw> openclaw config get session.resetTriggers

🦞 OpenClaw 2026.2.14 (c1feda1) — I can run local, remote, or purely on vibes—results may vary with DNS.

Config warnings:\n- plugins.entries.voice-call: plugin voice-call: duplicate plugin id detected; later plugin may be overridden (C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw\extensions\voice-call\index.ts)
Config path not found: session.resetTriggers
PS C:\Users\bengr.openclaw> openclaw config get session.resetTriggers

🦞 OpenClaw 2026.2.14 (c1feda1) — Because texting yourself reminders is so 2024.

Config warnings:\n- plugins.entries.voice-call: plugin voice-call: duplicate plugin id detected; later plugin may be overridden (C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw\extensions\voice-call\index.ts)
Config path not found: session.resetTriggers
PS C:\Users\bengr.openclaw>

PS C:\Users\bengr.openclaw> openclaw gateway status
Config warnings:\n- plugins.entries.voice-call: plugin voice-call: duplicate plugin id detected; later plugin may be overridden (C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw\extensions\voice-call\index.ts)
(C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw\extensions\voice-call\index.ts)
Config warnings:\n- plugins.entries.voice-call: plugin voice-call: duplicate plugin id detected; later plugin may be overridden (C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw\extensions\voice-call\index.ts)
Config warnings:\n- plugins.entries.voice-call: plugin voice-call: duplicate plugin id detected; later plugin may be overridden (C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw\extensions\voice-call\index.ts)
◇
Service: Scheduled Task (missing)
File logs: \tmp\openclaw\openclaw-2026-02-15.log
Command: C:\Program Files\nodejs\node.exe C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service env: OPENCLAW_GATEWAY_PORT=18789
Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json
Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.
Runtime: stopped (ERROR: The system cannot find the file specified.)
RPC probe: ok
Run: openclaw gateway install
File logs: \tmp\openclaw\openclaw-2026-02-15.log
Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
PS C:\Users\bengr.openclaw>

tiny shuttleBOT Feb 16, 2026, 7:07 AM

#

Two things in your paste strongly suggest this is still fixable via config, but we need to remove ambiguity first:

You didn’t actually run openclaw config get session.reset (you typed openclaw openclaw config …, hence unknown command 'openclaw'), so we still don’t know what reset policy the gateway is using.
Your current thread’s channel id is 147280…, but the session key you keep inspecting is 146668…. If you’re testing in one channel but inspecting the other channel’s session entry, it’ll look “random”.

Step 1 — prove you’re looking at the right session entry

Right after you send a Discord message that “resets”, run:

openclaw sessions --active 60 --json

Then find the entry whose updatedAt is “just now” and copy/paste that whole entry (or at least sessionKey, sessionId, updatedAt).

That guarantees we’re talking about the session that message actually hit.

Step 2 — check the reset knobs that must be stable now

#

Run these exactly:

openclaw config get session.resetByChannel.discord
openclaw config get session.reset
openclaw config get session

What we want to see:

session.resetByChannel.discord exists and is an object, not a quoted string
it contains {"mode":"idle","idleMinutes":10080} (or whatever you chose)

If session.resetByChannel.discord is missing, or looks like a string (you’ll see quotes around the whole JSON), re-set it like this:

openclaw config set session.resetByChannel.discord '{"mode":"idle","idleMinutes":10080}' --json

#

openclaw gateway restart

Step 3 — your gateway service state is weird (worth fixing)

openclaw gateway status shows:

Service: Scheduled Task (missing)
Runtime: stopped …
but also RPC probe: ok and Listening: 127.0.0.1:18789

That usually means the gateway is running “somehow”, but the Windows service wrapper isn’t installed/healthy, which can cause confusion and sometimes config drift.

Fix that baseline:

#

openclaw gateway install
openclaw gateway restart

If after Step 1 you can show that the same sessionKey: agent:main:discord:channel:<same id> gets a new sessionId one message later, and Step 2 confirms resetByChannel.discord.idleMinutes is really 10080, then it’s bug territory and we should grab the log lines around the reset reason and file a GitHub issue.

But first, paste:

the “just updated” session entry (with updatedAt)
output of openclaw config get session.resetByChannel.discord

rich vapor Feb 16, 2026, 7:41 AM

#

PS C:\Users\bengr.openclaw> openclaw config get session.resetByChannel.discord

🦞 OpenClaw 2026.2.14 (c1feda1) — If something's on fire, I can't extinguish it—but I can write a beautiful postmortem.

Config warnings:\n- plugins.entries.voice-call: plugin voice-call: duplicate plugin id detected; later plugin may be overridden (C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw\extensions\voice-call\index.ts)
{
"mode": "idle",
"idleMinutes": 10080
}
PS C:\Users\bengr.openclaw> openclaw config get session.reset

🦞 OpenClaw 2026.2.14 (c1feda1) — Automation with claws: minimal fuss, maximal pinch.

Config path not found: session.reset
PS C:\Users\bengr.openclaw> openclaw config get session

🦞 OpenClaw 2026.2.14 (c1feda1) — One CLI to rule them all, and one more restart because you changed the port.

Config warnings:\n- plugins.entries.voice-call: plugin voice-call: duplicate plugin id detected; later plugin may be overridden (C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw\extensions\voice-call\index.ts)
{
"resetByChannel": {
"discord": {
"mode": "idle",
"idleMinutes": 10080
}
}
}

tiny shuttleBOT Feb 16, 2026, 7:44 AM

#

Your config is correct, and it rules out “idle reset” as the cause:

session.resetByChannel.discord = { mode: "idle", idleMinutes: 10080 } ✅
No session.reset block at all (so nothing obvious overriding it) ✅

If the same session key:

agent:main:discord:channel:1466686796632166402

is getting a different sessionId one message later, with no gateway restart, the most likely explanation is:

You have more than one Gateway process handling Discord

When two gateway processes are running (or two different machines using the same Discord bot token), they each maintain their own in-memory session mapping and will overwrite sessions.json back and forth. That produces exactly what you’re seeing: sessionId flips every message even though reset settings are fine.

Your openclaw gateway status earlier already looks suspicious:

Service: Scheduled Task (missing)

#

Runtime: stopped (ERROR: The system cannot find the file specified.)
but also RPC probe: ok and Listening: 127.0.0.1:18789

That’s a classic “service management is broken / something else is running” smell.

1) Check for multiple running gateway processes (PowerShell)

Run:

Get-CimInstance Win32_Process |
  Where-Object { $_.CommandLine -match "openclaw.*gateway" } |
  Select-Object ProcessId, CommandLine

If you see more than one line, that’s your culprit.

Also consider: do you have OpenClaw running on another machine/VPS with the same Discord bot token? If yes, stop one of them (Discord should really be one gateway per bot token).

#

2) Fix the broken Windows service baseline

Get to a clean “single, supervised gateway” state:

openclaw gateway install
openclaw gateway restart
openclaw gateway status

Goal: Runtime: running (and still RPC probe: ok).

3) One more sanity check (to prove sessionId isn’t just from a different channel)

After sending a message in the channel, run:

openclaw sessions --active 60 --json

#

and confirm the same entry’s updatedAt moved forward and its sessionId did not change.

If you paste the output of the Get-CimInstance … openclaw.*gateway command, I can tell you immediately whether you’re in the “two gateways” situation.

rich vapor Feb 16, 2026, 7:48 AM

#

got this: PS C:\Users\bengr.openclaw> Get-CimInstance Win32_Process | Where-Object { $_.CommandLine -match "openclaw.*gateway" } | Select-Object ProcessId, CommandLine

ProcessId CommandLine

43996 "C:\Program Files\nodejs\node.exe" C:\Users\bengr\AppData\Roaming\npm/node_modules/openclaw/openclaw.mjs gateway
 8060 "C:\Program Files\nodejs\node.exe" --disable-warning=ExperimentalWarning C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw\openclaw.mjs gateway

tiny shuttleBOT Feb 16, 2026, 7:48 AM

#

That’s it — you have two Gateway processes running at the same time:

PID 43996 … openclaw.mjs gateway
PID 8060 … openclaw.mjs gateway

With two gateways, they’ll fight over the session store (sessions.json) and you’ll see exactly what you reported: same sessionKey, sessionId flipping “randomly” message-to-message.

Fix (pick one gateway, kill the other)

Option A (fastest): kill one of them

In PowerShell:

Stop-Process -Id 43996 -Force
# or instead:
# Stop-Process -Id 8060 -Force

#

Then immediately verify only one remains:

Get-CimInstance Win32_Process |
  Where-Object { $_.CommandLine -match "openclaw.*gateway" } |
  Select-Object ProcessId, CommandLine

And re-test: send 2 messages → check openclaw sessions --active 60 --json and confirm the sessionId stops changing.

Option B (cleanest): stop both, then restart exactly one (service-managed)

Stop-Process -Id 43996,8060 -Force
openclaw gateway install
openclaw gateway restart
openclaw gateway status

#

After that, do not also run openclaw gateway manually in a terminal — that’s how you end up with two again.

Why this caused “total memory loss”

Each gateway instance decides “current sessionId for this sessionKey” independently and writes it back. With two writers, you get session churn even with your resetByChannel.discord set correctly.

Once you’re down to exactly one gateway process, your session.resetByChannel.discord = { idleMinutes: 10080 } should behave as expected.

If you paste the output of openclaw gateway status after you’ve reduced it to one process, I can sanity-check you’re in the “stable” state.

rich vapor Feb 16, 2026, 7:50 AM

#

How do i tell which one I want to keep?

tiny shuttleBOT Feb 16, 2026, 7:52 AM

#

Keep the one that’s actually listening on the port your CLI/UI uses (almost always 18789), and kill the other.

1) Find which PID owns port 18789

In PowerShell:

Get-NetTCPConnection -LocalPort 18789 | Select-Object LocalAddress,LocalPort,State,OwningProcess

That OwningProcess is the gateway you want to keep.

If that command returns nothing, run this to see what ports each PID is listening on:

Get-NetTCPConnection -State Listen |
  Where-Object { $_.OwningProcess -in 43996,8060 } |

#

  Select-Object LocalAddress,LocalPort,State,OwningProcess

2) Inspect them (optional, helps pick)

Get-Process -Id 43996,8060 | Select-Object Id,StartTime,Path

Usually you keep the one with:

the port you expect (18789), and/or
the older StartTime (the “main” one)

3) Kill the other one

Once you know which PID is the “keeper”, kill the other:

#

Stop-Process -Id <the_other_pid> -Force

Then confirm you’re down to one:

Get-CimInstance Win32_Process |
  Where-Object { $_.CommandLine -match "openclaw.*gateway" } |
  Select-Object ProcessId, CommandLine

Strong recommendation (so it doesn’t happen again)

After you’re stable, install the Windows Scheduled Task service and use that to run the gateway (and don’t also run openclaw gateway manually in a terminal):

#

openclaw gateway install
openclaw gateway restart

If you paste the output of the Get-NetTCPConnection -LocalPort 18789 ... line, I’ll tell you exactly which PID to keep.

rich vapor Feb 16, 2026, 7:58 AM

#

PS C:\Users\bengr.openclaw> Get-NetTCPConnection -LocalPort 18789 | Select-Object LocalAddress,LocalPort,State,OwningProcess

LocalAddress LocalPort State OwningProcess

::1 18789 Listen 8060
127.0.0.1 18789 TimeWait 0
127.0.0.1 18789 TimeWait 0
127.0.0.1 18789 TimeWait 0
127.0.0.1 18789 TimeWait 0
127.0.0.1 18789 TimeWait 0
127.0.0.1 18789 Established 8060
127.0.0.1 18789 TimeWait 0
127.0.0.1 18789 TimeWait 0
127.0.0.1 18789 TimeWait 0
127.0.0.1 18789 Listen 8060
127.0.0.1 18789 TimeWait 0
127.0.0.1 18789 TimeWait 0
127.0.0.1 18789 TimeWait 0
127.0.0.1 18789 Established 8060
127.0.0.1 18789 TimeWait 0
127.0.0.1 18789 TimeWait 0
127.0.0.1 18789 TimeWait 0
127.0.0.1 18789 TimeWait 0
PS C:\Users\bengr.openclaw> Get-NetTCPConnection -State Listen | Where-Object { $_.OwningProcess -in 43996,8060 } | Select-Object LocalAddress,LocalPort,State,OwningProcess

LocalAddress LocalPort State OwningProcess

::1 18789 Listen 8060
127.0.0.1 18792 Listen 8060
127.0.0.1 18789 Listen 8060
PS C:\Users\bengr.openclaw> Get-Process -Id 43996,8060 | Select-Object Id,StartTime,Path

Id StartTime Path

8060 2/15/2026 4:37:24 PM C:\Program Files\nodejs\node.exe
43996 2/15/2026 4:37:24 PM C:\Program Files\nodejs\node.exe

PS C:\Users\bengr.openclaw>

tiny shuttleBOT Feb 16, 2026, 8:00 AM

#

Keep PID 8060.

Your output shows PID 8060 is the one actually bound and listening on the Gateway port:

::1:18789 Listen OwningProcess 8060
127.0.0.1:18789 Listen OwningProcess 8060
also 127.0.0.1:18792 Listen OwningProcess 8060 (extra listener)

PID 43996 is the “extra” gateway that’s causing session-store thrash.

Do this now

Stop-Process -Id 43996 -Force

Confirm you’re down to one gateway

#

Get-CimInstance Win32_Process |
  Where-Object { $_.CommandLine -match "openclaw.*gateway" } |
  Select-Object ProcessId, CommandLine

Then re-test session stability

Send 2–3 normal messages in the Discord channel and confirm the sessionId no longer flips:

openclaw sessions --active 60 --json

Prevent it from happening again

Since openclaw gateway status earlier said “Scheduled Task (missing)”, install the supervisor so you have a single canonical gateway and don’t accidentally start a second one in a terminal:

#

openclaw gateway install
openclaw gateway restart

After that: avoid running openclaw gateway manually unless you intentionally want a second instance on a different port/profile.

rich vapor Feb 16, 2026, 8:01 AM

#

Will I lose anything by deleting it? I think it happened when I set up sub agents

tiny shuttleBOT Feb 16, 2026, 8:02 AM

#

Killing/deleting the extra gateway process (PID 43996) won’t lose any durable data.

What you might “lose” is only in-flight / in-memory stuff that existed only inside that process, for example:

a currently running reply that hadn’t finished yet
any background tool/process state that hadn’t been persisted
transient queue items that were only in that process’s RAM

But the important durable bits are stored on disk and are shared:

config (~/.openclaw/openclaw.json)
session store + transcripts (~/.openclaw/agents/.../sessions/...)
memory files in your workspace

So the right move is still: stop the extra gateway so you stop corrupting session continuity.

Why it likely happened with subagents

#

Subagents themselves don’t require a second gateway, but it’s very common to accidentally start another gateway when:

running openclaw gateway manually in a second terminal,
or when a partial “service install”/restart leaves one running and you start another,
or when experimenting with different agent configs.

Safe sequence (minimal risk)

Stop the extra process:
```
Stop-Process -Id 43996 -Force
```
Confirm only one gateway remains.
Install/reinstall the Scheduled Task so you don’t accidentally spawn duplicates again:
```
openclaw gateway install
openclaw gateway restart
```

#

If you want to be extra cautious: wait until the bot is idle (not mid-response), then kill it.

rich vapor Feb 16, 2026, 8:10 AM

#

PS C:\Users\bengr.openclaw> openclaw gateway install
Config warnings:\n- plugins.entries.voice-call: plugin voice-call: duplicate plugin id detected; later plugin may be overridden (C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw\extensions\voice-call\index.ts)

🦞 OpenClaw 2026.2.14 (c1feda1) — Your task has been queued; your dignity has been deprecated.

│
◇ Config warnings ──────────────────────────────────────────────────────────────────────────╮
│ │
│ - plugins.entries.voice-call: plugin voice-call: duplicate plugin id detected; later │
│ plugin may be overridden │
│ (C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw\extensions\voice-call\index. │
│ ts) │
│ │
├────────────────────────────────────────────────────────────────────────────────────────────╯
Config warnings:\n- plugins.entries.voice-call: plugin voice-call: duplicate plugin id detected; later plugin may be overridden (C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw\extensions\voice-call\index.ts)
Gateway install failed: Error: schtasks create failed: ERROR: Access is denied.
Run PowerShell as Administrator or rerun without installing the daemon.
PS C:\Users\bengr.openclaw>

tiny shuttleBOT Feb 16, 2026, 8:11 AM

#

That error is just Windows being Windows: openclaw gateway install creates a Scheduled Task via schtasks, and on your machine it needs Administrator rights.

What to do

Option A (recommended): install the Scheduled Task as admin

Close any terminals that might be running openclaw gateway.
Make sure you only have one gateway process (kill the extra one if it’s still there):
```
Stop-Process -Id 43996 -Force
```
Open PowerShell / Windows Terminal “Run as Administrator”

Run:

openclaw gateway install
openclaw gateway restart
openclaw gateway status

#

After that, don’t also start openclaw gateway manually, or you’ll end up with two again.

Option B: don’t install a daemon (works, but you must babysit it)

If you don’t want to run as admin, you can just run one gateway manually in a terminal and leave it open. The key is: never start a second one.

About the `voice-call duplicate plugin id` warning

That warning is unrelated to the session reset issue. It means the voice-call plugin is being registered twice (usually from two extension locations). It’s annoying but not what’s flipping your sessionId.

If you want, paste openclaw config get plugins and I’ll tell you which duplicate to remove later — but first get to a single gateway + stable sessions.

rich vapor Feb 16, 2026, 8:28 AM

#

PS C:\windows\system32> Stop-Process -Id 43996 -Force
Stop-Process : Cannot find a process with the process identifier 43996.
At line:1 char:4

Stop-Process -Id 43996 -Force

+ CategoryInfo          : ObjectNotFound: (43996:Int32) [Stop-Process], ProcessCommandException
+ FullyQualifiedErrorId : NoProcessFoundForGivenId,Microsoft.PowerShell.Commands.StopProcessCommand

Getting this error

tiny shuttleBOT Feb 16, 2026, 8:28 AM

#

That error is good news: it means PID 43996 is already gone (so you successfully got down to one gateway).

Confirm you now only have one gateway process:

Get-CimInstance Win32_Process |
  Where-Object { $_.CommandLine -match "openclaw.*gateway" } |
  Select-Object ProcessId, CommandLine

You should see only PID 8060 (or whatever the remaining PID is).

Next steps

Re-test the original problem (sessionId flipping):
- Send 2–3 normal messages in the Discord channel
- Then run:

#

openclaw sessions --active 60 --json
```
The sessionId for the channel key should now stay stable.

About openclaw gateway install failing with “Access is denied”:
- If you want the gateway to survive reboots / not rely on an open terminal, you need to run that command in an Administrator PowerShell.
- If you’re okay keeping a terminal open, you can skip install and just avoid starting a second gateway.

If you paste the output of the “list gateway processes” command above, I’ll sanity-check you’re clean.

rich vapor Feb 16, 2026, 8:35 AM

#

PS C:\windows\system32> Get-CimInstance Win32_Process |

Where-Object { $_.CommandLine -match "openclaw.*gateway" } |
Select-Object ProcessId, CommandLine
PS C:\windows\system32>

Nothing shows up

tiny shuttleBOT Feb 16, 2026, 8:37 AM

#

If that command prints nothing, there are two common reasons:

The gateway isn’t running anymore (most likely), or
Win32_Process.CommandLine is coming back null (so your filter drops everything).

Let’s make it unambiguous by checking the port (this always works).

1) See if anything is listening on the gateway port

Get-NetTCPConnection -LocalPort 18789 | Select-Object LocalAddress,LocalPort,State,OwningProcess

If you get no rows (or no `Listen`)

Your gateway is not running right now.

Start it (manual, single instance):

#

openclaw gateway

Leave that window open. Then in a second terminal:

openclaw status

2) If it is listening, show what process it is

Take the OwningProcess PID from the port check and run:

Get-Process -Id <PID> | Select-Object Id,ProcessName,StartTime,Path

3) Why your CIM filter can show nothing even when running

Your filter uses CommandLine -match .... If CommandLine is null, it won’t match and you’ll see nothing. A safer variant is:

#

Get-CimInstance Win32_Process |
  Where-Object { $_.CommandLine -and $_.CommandLine -match "openclaw.*gateway" } |
  Select-Object ProcessId, CommandLine

Run the port check first though — that tells us immediately whether the gateway is up.

Once the gateway is confirmed running again, re-test the sessionId flip. With only one gateway process + your session.resetByChannel.discord setting, it should stop thrashing.

rich vapor Feb 16, 2026, 8:46 AM

#

Maybe it didn't work because my openclaw gateway wasn't running, started it again and ran these commands:
PS C:\windows\system32> Get-CimInstance Win32_Process | Where-Object { $_.CommandLine -match "openclaw.*gateway" } | Select-Object ProcessId, CommandLine

ProcessId CommandLine

22732 "C:\Program Files\nodejs\node.exe" C:\Users\bengr\AppData\Roaming\npm/node_modules/openclaw/openclaw.mjs g...
39724 "C:\Program Files\nodejs\node.exe" --disable-warning=ExperimentalWarning C:\Users\bengr\AppData\Roaming\np...

PS C:\windows\system32> Stop-Process -Id 43996 -Force
Stop-Process : Cannot find a process with the process identifier 43996.
At line:1 char:4

Stop-Process -Id 43996 -Force

+ CategoryInfo          : ObjectNotFound: (43996:Int32) [Stop-Process], ProcessCommandException
+ FullyQualifiedErrorId : NoProcessFoundForGivenId,Microsoft.PowerShell.Commands.StopProcessCommand

PS C:\windows\system32> Get-Process -Id <PID> | Select-Object Id,ProcessName,StartTime,Path
At line:1 char:17

Get-Process -Id <PID> | Select-Object Id,ProcessName,StartTime,Path
```
            ~
```

The '<' operator is reserved for future use.
+ CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : RedirectionNotSupported

tiny shuttleBOT Feb 16, 2026, 8:46 AM

#

Yep — you’re back to two gateways again, just with new PIDs (22732 and 39724). That’s why the sessionId flipping will come back.

Also: the <PID> thing is just a placeholder — PowerShell treats < as syntax, so you must replace it with a real number.

1) Figure out which PID owns port 18789 (keep that one)

Run:

Get-NetTCPConnection -LocalPort 18789 | Select-Object LocalAddress,LocalPort,State,OwningProcess

You’ll get an OwningProcess number. That is the gateway to keep.

2) Kill the other gateway PID

Let’s say the port owner is PID 22732. Then kill the other one:

#

Stop-Process -Id 39724 -Force

(or vice versa — keep the one that owns 18789, kill the other)

3) Confirm there’s only one left

Get-CimInstance Win32_Process |
  Where-Object { $_.CommandLine -and $_.CommandLine -match "openclaw.*gateway" } |
  Select-Object ProcessId, CommandLine

4) (Optional) inspect a PID correctly

Example:

#

Get-Process -Id 22732 | Select-Object Id,ProcessName,StartTime,Path

Important: how to stop re-creating the second gateway

Right now you’re starting the gateway manually, and something else is also starting one (another terminal, another profile, or a lingering background launcher).

Until you can install the Scheduled Task (admin required), the rule is:

Start openclaw gateway in exactly one terminal
Don’t run it again elsewhere
If you want a second instance for testing, it must be on a different port (and ideally different state/profile)

Run the port-owner command and paste the output — I’ll tell you exactly which PID to keep/kill.

rich vapor Feb 16, 2026, 8:47 AM

#

PS C:\windows\system32> Get-NetTCPConnection -LocalPort 18789 | Select-Object LocalAddress,LocalPort,State,OwningProcess

LocalAddress LocalPort State OwningProcess

::1 18789 Listen 39724
127.0.0.1 18789 Established 39724
127.0.0.1 18789 Listen 39724

tiny shuttleBOT Feb 16, 2026, 8:48 AM

#

Keep PID 39724 (it owns the listener on port 18789). Kill the other one (22732).

Run:

Stop-Process -Id 22732 -Force

Then confirm you’re down to one:

Get-CimInstance Win32_Process |
  Where-Object { $_.CommandLine -and $_.CommandLine -match "openclaw.*gateway" } |
  Select-Object ProcessId, CommandLine

Why this keeps happening

#

You’re likely starting the gateway twice (two terminals, or a terminal + some background launcher). Until you can install the Scheduled Task as admin, treat openclaw gateway like “start once and leave it”.

After killing PID 22732

Re-test the session stability:

send 2–3 messages in the Discord channel
check openclaw sessions --active 60 --json
The sessionId should stop flipping now that only one gateway is writing to the session store.

rich vapor Feb 16, 2026, 8:52 AM

#

PS C:\windows\system32> Stop-Process -Id 22732 -Force
PS C:\windows\system32> Get-CimInstance Win32_Process |

Where-Object { $.CommandLine -and $.CommandLine -match "openclaw.*gateway" } |
Select-Object ProcessId, CommandLine
PS C:\windows\system32> Get-NetTCPConnection -LocalPort 18789 | Select-Object LocalAddress,LocalPort,State,OwningProcess

I kill it, nothing returns, but the gateway stops. However when I start the gateway again (openclaw gateway)

PS C:\Users\bengr.openclaw> Get-CimInstance Win32_Process | Where-Object { $.CommandLine -match "openclaw.*gateway" } | Select-Object ProcessId, CommandLine
PS C:\Users\bengr.openclaw> Get-CimInstance Win32_Process | Where-Object { $.CommandLine -match "openclaw.*gateway" } | Select-Object ProcessId, CommandLine

ProcessId CommandLine

48244 "C:\Program Files\nodejs\node.exe" C:\Users\bengr\AppData\Roaming\npm/node_modules/openclaw/openclaw.mjs gateway
 6920 "C:\Program Files\nodejs\node.exe" --disable-warning=ExperimentalWarning C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw\openclaw.mjs gateway

Two gateways return

tiny shuttleBOT Feb 16, 2026, 8:56 AM

#

You’re not crazy — on Windows it’s common to see two Node PIDs after running openclaw gateway, and they are not always two independent gateways.

Right now you have two PIDs (48244 and 6920). The question is:

are these one gateway + its parent/wrapper (normal), or
two separate gateways (bad; causes sessionId thrash)

1) First: identify who actually owns the gateway port (18789)

Run:

Get-NetTCPConnection -LocalPort 18789 -State Listen |
  Select-Object LocalAddress,LocalPort,State,OwningProcess

The OwningProcess PID is the real gateway listener.

#

2) Check if the “other” PID is just the parent/wrapper (normal)

Run:

Get-CimInstance Win32_Process -Filter "ProcessId=48244 OR ProcessId=6920" |
  Select-Object ProcessId,ParentProcessId,CommandLine

Interpretation:

If one PID is the ParentProcessId of the other → that’s a single “gateway start” process tree. Keep both.
(If you kill the parent, the child gateway often dies too — which matches what you saw earlier.)
If they are not related (different parents) → you truly launched openclaw gateway twice. Kill the one that does not own port 18789.

3) If you want the simplest “clean slate” every time

Stop both PIDs, then start once:

#

Stop-Process -Id 48244,6920 -Force
openclaw gateway

Then do not run openclaw gateway in a second terminal.

4) Why this keeps reappearing

Because you don’t have the Scheduled Task installed (needs admin), the gateway is “manual only”, so it’s easy to accidentally start it twice. Long term fix is still:

Run PowerShell as Administrator:

openclaw gateway install
openclaw gateway restart

If you paste the output of steps (1) and (2), I’ll tell you exactly whether your current two PIDs are “normal parent/child” or “two gateways you need to kill”.

rich vapor Feb 16, 2026, 8:59 AM

#

PS C:\windows\system32> Get-NetTCPConnection -LocalPort 18789 -State Listen |

Select-Object LocalAddress,LocalPort,State,OwningProcess

LocalAddress LocalPort State OwningProcess

::1 18789 Listen 6920
127.0.0.1 18789 Listen 6920

PS C:\windows\system32> Get-CimInstance Win32_Process -Filter "ProcessId=48244 OR ProcessId=6920" |

Select-Object ProcessId,ParentProcessId,CommandLine

ProcessId ParentProcessId CommandLine

48244            1320 "C:\Program Files\nodejs\node.exe" C:\Users\bengr\AppData\Roaming\npm/node_modules/openclaw/openclaw.mjs gateway
 6920           48244 "C:\Program Files\nodejs\node.exe" --disable-warning=ExperimentalWarning C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw\openclaw.mjs gateway

so try and kill 48244 or no?

tiny shuttleBOT Feb 16, 2026, 9:00 AM

#

No — don’t kill 48244.

What you have right now is the normal parent/child situation:

6920 is the actual gateway (it owns port 18789)
48244 is its parent process (ParentProcessId of 6920 is 48244)

If you kill 48244, Windows will very often take down its child (6920) too — which matches what you observed (“gateway stops”).

What you should do instead

Leave both running.
The important thing is that you have only one listener on 18789, and you do: PID 6920.

Quick sanity check that there isn’t a second child gateway elsewhere:

#

Get-NetTCPConnection -State Listen |
  Where-Object { $_.LocalPort -eq 18789 } |
  Select-Object LocalAddress,LocalPort,OwningProcess

If it only shows PID 6920, you’re in the good state.

Re-test the original symptom now

Send a few Discord messages and confirm the channel sessionId stays stable:

openclaw sessions --active 60 --json

If the sessionId is still flipping with only one gateway listener, then we’ll look at logs for a reset reason — but the earlier “two independent gateways” issue is resolved in this process tree.

rich vapor Feb 16, 2026, 9:20 AM

#

tiny shuttle That error is just Windows being Windows: `openclaw gateway install` creates a *...

How do we know original wasn't the parent process

tiny shuttleBOT Feb 16, 2026, 9:20 AM

#

Because the “original vs parent” question is answered by two signals you already collected:

Who owns the listening socket on 18789
- Get-NetTCPConnection ... OwningProcess
- In your output, PID 6920 is the one with Listen on 127.0.0.1:18789 / ::1:18789.
- That means 6920 is the process that actually accepted the gateway bind (it’s the real gateway server).
Parent/child relationship
- Get-CimInstance ... ParentProcessId
- Your output shows:
  - 6920 has ParentProcessId = 48244
  - so 48244 spawned 6920.
- That’s the classic “launcher/wrapper” pattern: parent runs openclaw … gateway, then spawns the real gateway with extra Node flags (--disable-warning=ExperimentalWarning) and keeps supervising it.

So the one you want to treat as “the gateway” is the process that owns the port (6920). The parent (48244) isn’t listening; it’s supervising.

If you want one more confirmation, run:

#

Get-NetTCPConnection -State Listen |
  Where-Object { $_.OwningProcess -in 48244,6920 } |
  Select-Object LocalPort,OwningProcess

You should only see 18789 (and maybe 18792) under 6920, not 48244.

rich vapor Feb 16, 2026, 9:26 AM

#

Is there anying in this chat that puts me at jeopardy security wise? Whether that be knowledge about my computer or open claw bot?

tiny shuttleBOT Feb 16, 2026, 9:27 AM

#

What you’ve posted so far is low risk.

What’s visible in this chat

Your Windows username (bengr) and some local paths like C:\Users\bengr\...
That you run OpenClaw 2026.2.14, Node, and the gateway port (18789)
Some process IDs and that you have the voice-call extension installed (duplicate plugin warning)

That’s basically “system fingerprinting” info — mildly personal, but not something that lets anyone take over your machine or your bot.

What would be high risk (don’t post these)

Discord bot token (DISCORD_BOT_TOKEN / channels.discord.token)
Gateway auth token / password (gateway.auth.token, dashboard URLs with #token=...)
Any API keys (OpenAI/Anthropic/OpenRouter/etc)
Your full ~/.openclaw/openclaw.json if it contains secrets
Raw logs that include auth headers, pairing codes, or webhook secrets

Quick self-audit

#

Scroll/search the thread for: token, DISCORD_BOT_TOKEN, sk-, pk_, xox, OPENROUTER, ANTHROPIC, Authorization, #token=.
If none of those appear, you’re fine.

If you want to reduce exposure anyway

Delete any messages that show your username/paths (optional), and if you ever pasted a token/key even briefly: rotate it (that’s the only time I’d treat this as urgent).

rich vapor Feb 16, 2026, 9:30 AM

#

Do you have the power to delete my messages here

tiny shuttleBOT Feb 16, 2026, 9:30 AM

#

No — not directly.

I can’t “reach into Discord” and delete your messages on my own. Even if the bot has moderation perms, deletion requires the specific message IDs and the bot being explicitly coded/authorized to do that.

What you can do right now:

Delete your own messages: right‑click (or long‑press) the message → Delete Message.
Bulk cleanup: if you posted something sensitive and there are many messages, a moderator can bulk-delete in the channel (Discord permissions needed).

If you tell me why you want to delete them (privacy vs just noise), I can suggest the lowest-effort cleanup approach.

rich vapor Feb 16, 2026, 9:34 AM

#

Still happening btw. Memory loss after every message or couple of messages

tiny shuttleBOT Feb 16, 2026, 9:36 AM

#

If your session.resetByChannel.discord = { mode: "idle", idleMinutes: 10080 } is set (it is), then the only way you still get “memory loss” is one of these:

you’re not actually looking at the same session key (different Discord channel/thread id), or
there is still more than one Gateway instance processing Discord messages (could be on the same PC or another machine/WSL/VPS using the same Discord bot token), or
something is issuing a reset trigger (/new//reset) or a bug is forcing a new session (rare; needs logs).

Let’s make it unambiguous with a 60‑second “proof” loop.

A) Right after a message that “lost memory”, paste the most recently updated session entry

Run:

openclaw sessions --active 10 --json

Then paste the entry whose updatedAt is “just now” (or at least: sessionKey, sessionId, updatedAt).
This prevents the “I was watching the wrong channelId” issue.

#

B) At the same moment, confirm the gateway listener PID didn’t change

Run:

Get-NetTCPConnection -LocalPort 18789 -State Listen |
  Select-Object LocalAddress,LocalPort,OwningProcess

If OwningProcess changes between messages, your gateway is restarting/flapping (or you’re bouncing between instances).

C) Check whether you have two independent gateway trees (bad) vs one parent/child (normal)

Run:

Get-CimInstance Win32_Process |
  Where-Object { $_.CommandLine -and $_.CommandLine -match "openclaw\\.mjs.*gateway" } |

#

  Select-Object ProcessId,ParentProcessId,CommandLine

OK: exactly one parent/child pair like you had (child PID owns 18789, parent PID spawns it).
BAD: two different child PIDs each listening on some port, or two separate parents each spawning children (often means you started it twice or it’s running on another host too).

One key question (because it matches your symptoms perfectly)

Are you running OpenClaw anywhere else with the same Discord bot token? (WSL, another PC, a VPS, etc.)
If yes, stop the other one — Discord will happily deliver events to both, and you’ll get session thrash/confusion.

If you paste the outputs from A + B + C from one “memory loss” moment, I can tell which bucket you’re in and the exact fix.

rich vapor Feb 16, 2026, 9:47 AM

#

"updatedAt": 1771235040558,
"key": "agent:main:discord:channel:1466686796632166402",
"sessionId": "5defad8a-3353-4b5e-920c-df05e9ce3862",
"abortedLastRun": false,

tiny shuttleBOT Feb 16, 2026, 9:48 AM

#

That snippet just tells us what the session looks like right now — it doesn’t prove whether the sessionId is changing.

Let’s make it binary:

1) Confirm whether the same key is getting a new sessionId

Send a normal message in Discord: msg1
Immediately run:
```
openclaw sessions --active 10 --json
```
Find the entry for agent:main:discord:channel:1466686796632166402 and note the sessionId.
Send another message: msg2
Run the same command again and compare sessionId.

If the sessionId changed between msg1 and msg2, that’s not “model forgetting” — that’s session thrash.

2) Make sure you’re looking at the right Discord channel/thread id

#

Your thread metadata shows channel id 1472804783814344774, but you’re inspecting 1466686796632166402.

In Discord, enable Developer Mode → right‑click the channel/thread you’re actually typing in → Copy Channel ID.
Does it equal 1466686796632166402? If not, you’re checking the wrong session entry.

3) If sessionId is changing: prove you only have one gateway listener

Run:

Get-NetTCPConnection -LocalPort 18789 -State Listen |
  Select-Object LocalAddress,LocalPort,OwningProcess

And:

#

Get-CimInstance Win32_Process |
  Where-Object { $_.CommandLine -and $_.CommandLine -match "openclaw\\.mjs.*gateway" } |
  Select-Object ProcessId,ParentProcessId,CommandLine

If you paste the outputs from (1) (both sessionIds) + (2) (the channel ID you copied) + (3), I can tell exactly which case you’re in:

wrong channel/thread key being inspected, or
multiple gateways still handling Discord, or
something actually forcing resets (then we go to logs).

rich vapor Feb 16, 2026, 9:55 AM

#

I am not running the discord bot token anywhere else. The pid probably changed after I updated and restarted the gateway.
"updatedAt": 1771235437876,
"ageMs": 90461,
"sessionId": "15ebd095-a11f-4dee-93d4-16d8a56008c0"
"key": "agent:main:discord:channel:1466686796632166402",

However, these openclaw sessions audits have been after the update and restart
And this command didnt output anything:
Get-CimInstance Win32_Process |
Where-Object { $.CommandLine -and $.CommandLine -match "openclaw\.mjs.*gateway" } |
Select-Object ProcessId,ParentProcessId,CommandLine

tiny shuttleBOT Feb 16, 2026, 9:57 AM

#

Two separate issues are getting mixed together here:

PID changes after restart/update are normal (Windows process IDs change whenever you restart the gateway).
The real question is: does the same Discord “place” keep the same sessionKey and sessionId across two back‑to‑back messages?

Right now I still suspect you’re either:

watching the wrong channel/thread key, or
your session is stable but the model is “forgetting” for a different reason.

1) First: make sure you’re checking the right Discord channel/thread ID

Your thread metadata shows channel id 1472804783814344774, but you keep inspecting:

agent:main:discord:channel:1466686796632166402

If you’re posting in the thread but checking the parent channel (or vice‑versa), it’ll look like “random resets”.

Do this in Discord (Developer Mode on):

#

Right‑click the exact thread/channel you are typing in → Copy Channel ID
That ID must match the number in agent:main:discord:channel:<id> for the session you care about.

2) List the Discord channel session keys you actually have “active”

Run:

openclaw sessions --active 60 --json | Select-String "agent:main:discord:channel:"

You should see both the parent channel and the thread (if Discord treats them separately). Pick the one that matches the ID you copied.

3) Prove/disprove “sessionId changes between adjacent messages”

Once you’ve identified the correct sessionKey:

Send message msg1
Run openclaw sessions --active 10 --json and note sessionId for that exact key

#

Send message msg2
Run again and compare

If sessionId changes between msg1 and msg2 without a restart, that’s session thrash.

4) Why your process command might have shown nothing

This part is just PowerShell regex/escaping: you don’t want \\.. Use either:

Get-CimInstance Win32_Process |
  Where-Object { $_.CommandLine -and $_.CommandLine -match "openclaw.*gateway" } |
  Select-Object ProcessId,ParentProcessId,CommandLine

Or skip CommandLine entirely (more reliable) and just check who owns the port:

#

Get-NetTCPConnection -LocalPort 18789 -State Listen |
  Select-Object LocalAddress,LocalPort,OwningProcess

What I need from you to close this

Paste:

the Discord Channel ID you copied from the exact place you’re chatting
the matching sessionKey + sessionId after msg1
the matching sessionKey + sessionId after msg2

Then we’ll know with certainty whether this is still session resets, or just “you’re looking at the parent session while chatting in a thread”.

rich vapor Feb 16, 2026, 10:06 AM

#

1466686796632166402
PS C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw> openclaw sessions --active 60 --json | Select-String "agent:main:discord:channel:"
Config warnings:\n- plugins.entries.voice-call: plugin voice-call: duplicate plugin id detected; later plugin may be overridden (C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw\extensions\voice-call\index.ts)

"key": "agent:main:discord:channel:1466686796632166402",

PS C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw> openclaw sessions --active 10 --json
Config warnings:\n- plugins.entries.voice-call: plugin voice-call: duplicate plugin id detected; later plugin may be overridden (C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw\extensions\voice-call\index.ts)
{
"path": "C:\Users\bengr\.openclaw\agents\main\sessions\sessions.json",
"count": 1,
"activeMinutes": 10,
"sessions": [
{
"key": "agent:main:discord:channel:1466686796632166402",
"kind": "group",
"updatedAt": 1771235834533,
"ageMs": 11334,
"sessionId": "15ebd095-a11f-4dee-93d4-16d8a56008c0",
"systemSent": true,
"abortedLastRun": false,
"inputTokens": 148386,
"outputTokens": 1784,
"totalTokens": 40851,
"totalTokensFresh": true,
"model": "MiniMax-M2.5",
"contextTokens": 200000
}
]
}
PS C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw> openclaw sessions --active 60 --json | Select-String "agent:main:discord:channel:"
Config warnings:\n- plugins.entries.voice-call: plugin voice-call: duplicate plugin id detected; later plugin may be overridden (C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw\extensions\voice-call\index.ts)

  "key": "agent:main:discord:channel:1466686796632166402",

PS C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw> openclaw sessions --active 10 --json
Config warnings:\n- plugins.entries.voice-call: plugin voice-call: duplicate plugin id detected; later plugin may be overridden (C:\Users\bengr\AppData\Roaming\npm\node_modules\openclaw\extensions\voice-call\index.ts)
{
"path": "C:\Users\bengr\.openclaw\agents\main\sessions\sessions.json",
"count": 2,
"activeMinutes": 10,
"sessions": [
{
"key": "agent:main:discord:channel:1466686796632166402",
"kind": "group",
"updatedAt": 1771236211493,
"ageMs": 14885,
"sessionId": "15ebd095-a11f-4dee-93d4-16d8a56008c0",
"systemSent": true,
"abortedLastRun": false,
"inputTokens": 615474,
"outputTokens": 1235,
"totalTokens": 81182,
"totalTokensFresh": true,
"model": "MiniMax-M2.5",
"contextTokens": 200000
},
{
"key": "agent:main:discord:channel:1472785793067257968",
"kind": "group",
"updatedAt": 1771236119134,
"ageMs": 107244,
"sessionId": "98b3bcc3-ba17-4c88-befb-a740b27313e7",
"totalTokens": null,
"totalTokensFresh": false,
"model": "MiniMax-M2.5",
"contextTokens": 200000
}
]
}

Second command is after I instructed main agent to communicate with sub agents

PS C:\Users\bengr> Get-NetTCPConnection -LocalPort 18789 -State Listen |

Select-Object LocalAddress,LocalPort,OwningProcess

LocalAddress LocalPort OwningProcess

::1 18789 3112
127.0.0.1 18789 3112

tiny shuttleBOT Feb 16, 2026, 10:06 AM

#

This is actually great data — it shows your Discord channel session is stable now:

Key: agent:main:discord:channel:1466686796632166402
SessionId stayed the same: 15ebd095-a11f-4dee-93d4-16d8a56008c0
Tokens are accumulating (so it’s not resetting)
Gateway listener PID is a single PID owning 18789 (3112) ✅

So the “memory loss every message” you feel in chat is not coming from a new sessionId anymore.

What did happen: you now have two different Discord channel sessions

Your second snapshot shows a second key:

agent:main:discord:channel:1472785793067257968 with sessionId 98b3…

That means you (or Discord) are sometimes sending messages in a different Discord channel/thread than 146668… (or OpenClaw is receiving events from another channel you didn’t realize you were interacting in).

This perfectly explains the “memory loss”: you’re switching between two different session keys, each with its own context.

#

Action: identify what `1472785793067257968` is

In Discord with Developer Mode enabled:

Use “Copy Channel ID” around the places you’re chatting (channel + thread) and see which one equals 1472785793067257968.

Or from CLI (if available in your build), use:

openclaw sessions --active 120 --json

and look for origin fields (label/subject/room) for that second entry. Some installs include that metadata.

Why it appeared “after I instructed main agent to communicate with sub agents”

Two possibilities:

The instruction caused the bot to post somewhere else (another channel or thread), updating a different session key.
Discord events (like bot messages, system events, or thread metadata) are being attributed to a different channel ID.

Next: lock routing down so you don’t accidentally create sessions in other channels

Make sure your Discord allowlist only includes the channel/thread you actually want, and deny the rest. In config terms that means using channels.discord.guilds.<guildId>.channels.<channelId>.allow: true and not allowing wildcard channels.

#

Quick confirmation test

Send 3 messages only in the same Discord place (same channel/thread UI), then run:

openclaw sessions --active 10 --json

If only the 146668... entry updates and its sessionId stays the same, you’re stable — any “forgetting” at that point is model/context behavior, not sessions.

If you paste the Discord name/link of the channel/thread you intend to use, I can suggest the exact allowlist shape so only that place is routed (and the phantom 147278… stops getting traffic).

sinful brook Feb 16, 2026, 10:07 AM

#

Sharing my findings here: https://github.com/openclaw/openclaw/issues/17520

My thread of report: https://discord.com/channels/1456350064065904867/1472649410088403115

Perhaps can be a good reference for you.

TLDR on my case, nothing can be done and need to wait for new version with fix on their base code, not an issue on our configuration (probably).

But yeah giving as much details to them would be helpful I think, and perhaps with more reports on the github

tiny shuttleBOT Feb 16, 2026, 10:07 AM

#

Thanks — that’s a useful reference.

One nuance for this particular “memory loss” symptom (that I’d highlight in the GitHub issue / for anyone reading your thread):

There are two different failure modes that look identical in chat:
1. Session churn: same sessionKey, but sessionId changes (true reset / config / multiple gateways).
2. Session switching: you actually have multiple agent:main:discord:channel:<id> keys getting traffic (thread vs parent channel vs another channel), so the bot “forgets” because you’re in a different session.

In the debug you posted earlier, the key agent:main:discord:channel:146668… kept the same sessionId, but a second channel key agent:main:discord:channel:147278… appeared — that strongly suggests mode (2) is at least part of the story for some users.

So: it may still be a core bug, but asking reporters to include both:

openclaw sessions --active 60 --json (showing all discord channel keys touched)
plus the Discord UI “Copy Channel ID” for the exact place they typed

…will help maintainers distinguish “reset” vs “wrong channel id / thread mapping”.

If you want, I can draft a short “please include this diagnostic block” comment you (or others) can paste into that GitHub issue without pinging anyone.

rich vapor Feb 16, 2026, 10:09 AM

#

sinful brook Sharing my findings here: https://github.com/openclaw/openclaw/issues/17520 My ...

Thank you. Looks I am just going to give up. Wasted so much time/tokens this weekend trying to fix it

tiny shuttleBOT Feb 16, 2026, 10:10 AM

#

Totally fair to call it. Discord session weirdness is one of the most expensive bugs to “debug by chat” because every test costs tokens and attention.

Before you bail completely, two low-effort options that avoid more token burn:

1) Freeze the bleeding (cheap + practical)

Run OpenClaw only when you’re actively testing, and force fresh context explicitly:

use /new at the start of any “real” interaction
keep Discord usage to short bursts until the upstream fix lands

That avoids long conversations getting split across keys / sessions.

2) Leave a high-signal breadcrumb for maintainers (no more experiments)

If you post one final update to the GitHub issue (or your Discord thread), make it just this:

your openclaw --version
openclaw sessions --active 60 --json (redact if needed)
the Discord Copy Channel ID of where you typed

#

whether sessionId was changing for the same key vs you saw multiple discord channel keys

That’s enough for someone on main to reproduce/triage without you spending more tokens.

If you want, paste your latest openclaw sessions --active 60 --json here and I’ll tell you exactly which 5 lines to include in the issue (so you don’t dump a wall of JSON).

sinful brook Feb 16, 2026, 10:11 AM

#

Yea I spend all night trying to figure it out.

In the meantime, my recommendation:

FOcus on using webchat while waiting for fix, its not using the same session as 3rd party app, so you wont have that issue there at all
If you want to use that dashboard on mobile, connect your pc and mobile to tailscale, get your agent to set it up for you and you can chat via mobile (altho web not app).
Make sure to also file the additional report on github

tiny shuttleBOT Feb 16, 2026, 10:11 AM

#

That’s solid advice from ET.

One clarification so expectations are set correctly:

WebChat is its own channel/session key, so it’s a good “stable fallback” while Discord is flaky.
You can still have long-lived sessions there, and you won’t be mixing in Discord thread/channel IDs at all.

If you want the least-friction setup while you wait for upstream fixes:

Use WebChat for anything that needs continuity.
Keep Discord for “ping the bot / quick question” only.
If you do WebChat-on-mobile, Tailscale is the right way. Just keep the gateway bound to loopback and expose via Tailscale Serve / funnel only if you understand the auth tradeoffs (device identity/pairing comes into play).

And yes: extra GitHub reports help, but only if they include:

exact OpenClaw version
which Discord IDs are involved (channel + thread IDs)
whether sessionId flips for the same sessionKey or whether you see multiple keys

#

If bgriff26 wants, I can provide a short copy/paste “report template” they can drop into issue #17520 without running more experiments.

rich vapor Feb 16, 2026, 10:16 AM

#

Provide a report template but redact my discord ID's, session keys, and thread ID's

tiny shuttleBOT Feb 16, 2026, 10:16 AM

#

Here’s a copy/paste report template you can drop into issue #17520 (or a new issue). It’s written so you can redact Discord IDs, session keys, thread IDs while still being useful.

Environment

OpenClaw version: 2026.2.14 (commit: c1feda1)
OS: Windows (PowerShell)
Channel: Discord (guild channel + possibly threads)
Gateway mode/bind: loopback (127.0.0.1:18789)
Install type: (npm/git) + whether openclaw gateway install is used (Scheduled Task) or manual openclaw gateway
- Note: openclaw gateway install fails with Access is denied unless run as Administrator (Windows).

Symptom

In Discord, the agent appears to “forget” context after every message or every few messages.
This looks like either:
- Session churn (same sessionKey but sessionId changes), and/or
- Session switching (messages sometimes land in a different sessionKey due to threads/parent channel mapping).

#

What I expected

Messages in the same Discord channel/thread should reuse the same session (same sessionKey and stable sessionId over time).

What I observed (redacted)

1) Session reset behavior

Session keys involved:
- agent:main:discord:channel:<REDACTED_CHANNEL_ID_1>
- agent:main:discord:channel:<REDACTED_CHANNEL_ID_2> (unexpected / appears intermittently)
In some runs, the sessionId for <REDACTED_CHANNEL_ID_1> changes between adjacent messages even without gateway restart.
(If this is “session switching” instead, note that here.)

2) Reset config check

I set:

session: {
  resetByChannel: {

#

    discord: { mode: "idle", idleMinutes: 10080 } // 7 days
  }
}

Verified via:

openclaw config get session.resetByChannel.discord
openclaw config get session

3) Gateway process / port sanity checks (Windows)

At various points I found multiple gateway-related Node processes.

I used these commands to debug:

Get-NetTCPConnection -LocalPort 18789 -State Listen |

#

  Select-Object LocalAddress,LocalPort,OwningProcess

Get-CimInstance Win32_Process |
  Where-Object { $_.CommandLine -and $_.CommandLine -match "openclaw.*gateway" } |
  Select-Object ProcessId,ParentProcessId,CommandLine

Sometimes this produced two PIDs, and in at least one case there were two independent gateway instances vs a normal parent/child pair.

Reproduction steps (minimal)

Start gateway (openclaw gateway) and connect Discord bot.
Send message A in a Discord channel/thread.
Send message B in the same place.
Inspect sessions:

openclaw sessions --active 10 --json

#

Observe whether:

same Discord place → same sessionKey, stable sessionId (expected), or
sessionId changes / multiple discord:channel keys get updated unexpectedly (bug).

Evidence (sanitized)

Paste a short excerpt from openclaw sessions --active 10 --json with:
- key: "agent:main:discord:channel:<REDACTED>"
- sessionId: "<REDACTED_UUID>"
- updatedAt, ageMs
- (Optional) any second agent:main:discord:channel:<REDACTED> entry that appears

Example (sanitized):

{
  "key": "agent:main:discord:channel:<REDACTED>",
  "sessionId": "<REDACTED>",

#

  "updatedAt": <timestamp>,
  "ageMs": <ms>
}

Notes / hypotheses

Might be Discord thread/parent channel ID mapping causing session switching.
Might be multiple gateway processes competing for session store on Windows.
Might be a core bug in Discord session routing/session store updates on Windows (see issue #17520).

If you want, paste your redacted openclaw sessions --active 10 --json snippet here and I’ll help you tighten it down to the smallest “maintainer-friendly” evidence block.

rich vapor Feb 16, 2026, 10:34 AM

#

Can we delete this post

tiny shuttleBOT Feb 16, 2026, 10:34 AM

#

I can’t delete it from here.

On Discord you can delete your own message:

Hover the message → click the … menu
Delete Message (confirm)

If it’s not your message (or Discord won’t let you delete it), you’ll need a server mod/admin to remove it.

rich vapor Feb 16, 2026, 10:37 AM

#

Nothing sensitive for me here correct?

tiny shuttleBOT Feb 16, 2026, 10:39 AM

#

Correct — nothing you’ve shared here looks like a “rotate immediately” secret.

What’s in the thread is mostly:

your Windows username (bengr) + local file paths
OpenClaw version/commit, port 18789
process IDs and session IDs / channel IDs (IDs aren’t secrets)

That’s minor privacy/fingerprinting info, but it doesn’t let anyone access your machine or your bot.

The only things that would be sensitive (and I haven’t seen you post) are:

Discord bot token
gateway token/password / dashboard URL containing #token=...
model provider API keys

If you didn’t paste any of those, you’re good.

olive tundra Feb 18, 2026, 12:27 AM

#

@rich vapor Did you ever get to the bottom of this? I had to downgrade to 2026.2.12 all versions after that have this issue, for me it refreshes memory after each whatsapp message, so it's not limited to just Discord.

tiny shuttleBOT Feb 18, 2026, 12:35 AM

#

I never saw a single “one bug fixed by X” root-cause for this yet — but when OpenClaw “forgets everything after every message”, it’s almost always because it’s minting a new sessionId every turn (so there’s effectively no chat history to load), even though the transport (WhatsApp/Discord) is fine.

The two most common causes I’ve seen:

Session reset policy effectively set to “always reset”

Check your config for any of these being 0:
- session.idleMinutes: 0
- session.reset.idleMinutes: 0
- session.resetByType.<...>.idleMinutes: 0

idleMinutes: 0 means “immediately stale” → new session every message.

Session store not being written/read consistently

The gateway persists session metadata in:
~/.openclaw/agents/<agentId>/sessions/sessions.json
If that file can’t be updated (permissions, different $OPENCLAW_STATE_DIR/HOME between service vs CLI, etc.), you’ll see “new session every time” behavior.

#Total Memory Loss after Each Message

Quick things to check (most likely causes)

1) Are you accidentally creating “thread-like” identities each message?

2) Is the Gateway restarting/crashing between messages?

3) Is session reset configured way too aggressively?

4) Is the session store failing to persist?

Why the “subagent leaks into general” detail matters

Docs pointers (so we’re aligned on expected behavior)

Is “89 total sessions” normal?

One important sanity check (because your earlier symptom contradicts “store healthy”)

1) Session reset knobs to check / set

A) session.reset (global)

B) session.resetByChannel.discord (Discord-specific override)

C) session.resetByType

D) session.resetTriggers

2) Quick “make it stop” config (PowerShell-safe)

3) Verify you’re editing the gateway’s config

4) One more key test (to confirm it’s “idleMinutes” vs “literally every message”)

Why the bot’s answers contradict

The reliable way to confirm if you actually reset

If you want, paste the two session entries (channel + slash) from that JSON

1) Collect sessions (last hour)

2) Find the Discord channel + slash entries (PowerShell)

What I expect we’ll see

What’s most likely happening

What to do next (to fully close this out)

Bottom line

1) First: confirm you’re comparing the same session key

2) Check the effective reset knobs (now that session exists)

3) Make sure the gateway service is using the same config you’re editing

4) Quick “belt + suspenders” hardening (optional)

5) If it still flips: grab the reason from logs

Step 1 — prove you’re looking at the right session entry

Step 2 — check the reset knobs that must be stable now

Step 3 — your gateway service state is weird (worth fixing)

You have more than one Gateway process handling Discord

1) Check for multiple running gateway processes (PowerShell)

2) Fix the broken Windows service baseline

3) One more sanity check (to prove sessionId isn’t just from a different channel)

Fix (pick one gateway, kill the other)

Option A (fastest): kill one of them

Option B (cleanest): stop both, then restart exactly one (service-managed)

Why this caused “total memory loss”

1) Find which PID owns port 18789

2) Inspect them (optional, helps pick)

3) Kill the other one

Strong recommendation (so it doesn’t happen again)

Do this now

Confirm you’re down to one gateway

Then re-test session stability

Prevent it from happening again

Why it likely happened with subagents

Safe sequence (minimal risk)

What to do

Option A (recommended): install the Scheduled Task as admin

Option B: don’t install a daemon (works, but you must babysit it)

About the voice-call duplicate plugin id warning

Next steps

1) See if anything is listening on the gateway port

If you get no rows (or no Listen)

2) If it is listening, show what process it is

3) Why your CIM filter can show nothing even when running

1) Figure out which PID owns port 18789 (keep that one)

2) Kill the other gateway PID

3) Confirm there’s only one left

4) (Optional) inspect a PID correctly

Important: how to stop re-creating the second gateway

Why this keeps happening

After killing PID 22732

1) First: identify who actually owns the gateway port (18789)

2) Check if the “other” PID is just the parent/wrapper (normal)

3) If you want the simplest “clean slate” every time

4) Why this keeps reappearing

What you should do instead

Re-test the original symptom now

What’s visible in this chat

What would be high risk (don’t post these)

Quick self-audit

If you want to reduce exposure anyway

A) Right after a message that “lost memory”, paste the most recently updated session entry

A) `session.reset` (global)

B) `session.resetByChannel.discord` (Discord-specific override)

C) `session.resetByType`

D) `session.resetTriggers`

2) Check the effective reset knobs (now that `session` exists)

About the `voice-call duplicate plugin id` warning

If you get no rows (or no `Listen`)

Action: identify what `1472785793067257968` is