openclaw - ✅(Solved) Fix [Bug]: session key write still hardcodes DEFAULT_AGENT_ID after PR #30654 (regression of #29683) [3 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#63992Fetched 2026-04-10 03:41:25
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
Participants
Timeline (top)
labeled ×1

On 2026.4.8 when you try to set your agents.list[] and have one set to default: true, sessions are still stored/routed to ~/.openclaw/agents/main/sessions. I also propose that we should have a agents.list[].sessionsDir to go with agents.list[].agentDir to help with this.

For example I have:

  "agents": {
    "list": [
      {
        "default": true,
        "id": "ops",
        "name": "Ops",
        "workspace": "/home/node/.openclaw/workspace",
        "agentDir": "/home/node/.openclaw/agents/ops/agent"
      },
      {
        "id": "cipher",
        "name": "Cipher",
        "workspace": "/home/node/.openclaw/workspace-cipher",
        "agentDir": "/home/node/.openclaw/agents/cipher/agent"
      }
    ]
  }

Cipher goes to agents/cipher/sessions no problem, but Ops goes to agents/main/sessions even though it isn't set to do so.

The channel I have configured is Discord - so that might help, since it could be that plugin causing this behaviour.

And in the official discord channel I have the thread #1491458068209471629 in the #help text channel. Where I was told I should mention #29683 and PR's: PR #30654, PR #57217.

fix options:

  • pass cfg into resolveSessionKey() and use resolveDefaultAgentId(cfg) instead of the hardcoded constant
  • wrap remaining resolveSessionKey() call sites with canonicalizeMainSessionAlias() (find with grep -r "resolveSessionKey(" extensions/ src/)

This next bit is TL;DR; but I'm putting it here as a summary from the discord thread just for completeness:

you're right — this is a real bug.

root cause:
resolveSessionKey() in src/config/sessions/session-key.ts hardcodes DEFAULT_AGENT_ID="main", ignoring your custom default agent. session keys are written incorrectly to ~/.openclaw/agents/main/sessions/ even when configured for ops.

existing partial fixes:
- PR #30654: wrapped 3 call sites but didn’t fix the core function
- PR #57217: only cleans up old orphaned keys, does not prevent new bad writes

why it still fails for you:
uncovered call sites (e.g., slack extension) still use the broken function directly.

help maintainers: share which channel you used (telegram/discord/slack/web/signal/mattermost)

how to file the bug:
1. github: https://github.com/openclaw/openclaw/issues/new (bug template)
2. title: session key write still hardcodes DEFAULT_AGENT_ID after PR #30654 (regression of #29683)
3. body: version, agents.list config snippet, channel, symptom, reference #29683, PR #30654, PR #57217

fix options:
- pass cfg into resolveSessionKey() and use resolveDefaultAgentId(cfg) instead of the hardcoded constant
- wrap remaining resolveSessionKey() call sites with canonicalizeMainSessionAlias() (find with grep -r "resolveSessionKey(" extensions/ src/)

tldr: i was wrong earlier — this is a real bug with an incomplete fix. please file the issue. ❤️

Root Cause

root cause: resolveSessionKey() in src/config/sessions/session-key.ts hardcodes DEFAULT_AGENT_ID="main", ignoring your custom default agent. session keys are written incorrectly to ~/.openclaw/agents/main/sessions/ even when configured for ops.

PR fix notes

PR #2: Fix #63992: resolveSessionKey hardcodes DEFAULT_AGENT_ID instead of using configured default agent

Description (problem / solution / changelog)

Summary

Fixes #63992

Changes

  • src/config/sessions/session-key.ts:

    • Added import for OpenClawConfig and resolveDefaultAgentId
    • Removed unused DEFAULT_AGENT_ID import
    • Added optional cfg?: OpenClawConfig parameter to resolveSessionKey
    • Replaced hardcoded DEFAULT_AGENT_ID with resolveDefaultAgentId(cfg ?? {})
  • src/agents/command/session.ts:

    • Updated call site to pass opts.cfg to resolveSessionKey

Problem

resolveSessionKey() was hardcoding DEFAULT_AGENT_ID ("main") when building session keys for non-group chats, ignoring any configured default agent. This was a regression from PR #30654.

Solution

Pass the OpenClawConfig to resolveDefaultAgentId() so that user-defined default agents are respected when resolving session keys. Backward compatible for call sites that don't pass cfg (they get the default "main" agent).

Changed files

  • extensions/minimax/image-generation-provider.ts (modified, +24/-8)
  • src/agents/command/session.ts (modified, +1/-1)
  • src/config/sessions/session-key.ts (modified, +6/-4)

PR #3: Fix #63992: resolveSessionKey hardcodes DEFAULT_AGENT_ID instead of using configured default agent

Description (problem / solution / changelog)

Summary

Fixes #63992

Problem

resolveSessionKey() was hardcoding DEFAULT_AGENT_ID ("main") when building session keys for non-group chats, ignoring any configured default agent. This was a regression from PR #30654.

Changes

Root fix (src/config/sessions/session-key.ts)

  • Added OpenClawConfig import
  • Added resolveDefaultAgentId import from agent-scope.ts
  • Added optional cfg?: OpenClawConfig parameter to resolveSessionKey
  • Replaced hardcoded DEFAULT_AGENT_ID with resolveDefaultAgentId(cfg ?? {})

Call site fixes

  • src/agents/command/session.ts: pass opts.cfg to resolveSessionKey
  • extensions/slack/src/monitor/context.ts: pass params.cfg to resolveSessionKey

Notes

Some call sites (whatsapp, auto-reply/reply/session.ts) already use canonicalizeMainSessionAlias as a workaround and are unaffected by this change. The fix is backward compatible - call sites that don't pass cfg will continue to use DEFAULT_AGENT_ID="main".

Testing

Existing tests pass. The fix allows custom default agents (e.g., default: true on a non-main agent) to be properly respected when resolving session keys.

Changed files

  • extensions/slack/src/monitor/context.ts (modified, +1/-0)
  • src/agents/command/session.ts (modified, +1/-1)
  • src/config/sessions/session-key.ts (modified, +6/-4)

PR #64108: Fix #63992: resolveSessionKey hardcodes DEFAULT_AGENT_ID instead of using configured default agent

Description (problem / solution / changelog)

Summary

Fixes #63992

Problem

resolveSessionKey() was hardcoding DEFAULT_AGENT_ID ("main") when building session keys for non-group chats, ignoring any configured default agent. This was a regression from PR #30654.

Changes

Root fix (src/config/sessions/session-key.ts)

  • Added OpenClawConfig import
  • Added resolveDefaultAgentId import from agent-scope.ts
  • Added optional cfg?: OpenClawConfig parameter to resolveSessionKey
  • Replaced hardcoded DEFAULT_AGENT_ID with resolveDefaultAgentId(cfg ?? {})

Call site fixes

  • src/agents/command/session.ts: pass opts.cfg to resolveSessionKey
  • extensions/slack/src/monitor/context.ts: pass params.cfg to resolveSessionKey

Notes

Some call sites (whatsapp, auto-reply/reply/session.ts) already use canonicalizeMainSessionAlias as a workaround and are unaffected by this change. The fix is backward compatible - call sites that don't pass cfg will continue to use DEFAULT_AGENT_ID="main".

Testing

Existing tests pass. The fix allows custom default agents (e.g., default: true on a non-main agent) to be properly respected when resolving session keys.

Changed files

  • extensions/slack/src/monitor/context.ts (modified, +1/-0)
  • src/agents/command/session.ts (modified, +24/-8)
  • src/config/sessions/session-key.ts (modified, +58/-4)

Code Example

"agents": {
    "list": [
      {
        "default": true,
        "id": "ops",
        "name": "Ops",
        "workspace": "/home/node/.openclaw/workspace",
        "agentDir": "/home/node/.openclaw/agents/ops/agent"
      },
      {
        "id": "cipher",
        "name": "Cipher",
        "workspace": "/home/node/.openclaw/workspace-cipher",
        "agentDir": "/home/node/.openclaw/agents/cipher/agent"
      }
    ]
  }

---

you're right — this is a real bug.

root cause:
resolveSessionKey() in src/config/sessions/session-key.ts hardcodes DEFAULT_AGENT_ID="main", ignoring your custom default agent. session keys are written incorrectly to ~/.openclaw/agents/main/sessions/ even when configured for ops.

existing partial fixes:
- PR #30654: wrapped 3 call sites but didn’t fix the core function
- PR #57217: only cleans up old orphaned keys, does not prevent new bad writes

why it still fails for you:
uncovered call sites (e.g., slack extension) still use the broken function directly.

help maintainers: share which channel you used (telegram/discord/slack/web/signal/mattermost)

how to file the bug:
1. github: https://github.com/openclaw/openclaw/issues/new (bug template)
2. title: session key write still hardcodes DEFAULT_AGENT_ID after PR #30654 (regression of #29683)
3. body: version, agents.list config snippet, channel, symptom, reference #29683, PR #30654, PR #57217

fix options:
- pass cfg into resolveSessionKey() and use resolveDefaultAgentId(cfg) instead of the hardcoded constant
- wrap remaining resolveSessionKey() call sites with canonicalizeMainSessionAlias() (find with grep -r "resolveSessionKey(" extensions/ src/)

tldr: i was wrong earlier — this is a real bug with an incomplete fix. please file the issue. ❤️

---

There are no errors in logs, its only visible by looking at the folder within `~/.openclaw/agents/main/sessions` and monitoring it as you speak with the agent via Discord. It is possible this affects other channels too.
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

On 2026.4.8 when you try to set your agents.list[] and have one set to default: true, sessions are still stored/routed to ~/.openclaw/agents/main/sessions. I also propose that we should have a agents.list[].sessionsDir to go with agents.list[].agentDir to help with this.

For example I have:

  "agents": {
    "list": [
      {
        "default": true,
        "id": "ops",
        "name": "Ops",
        "workspace": "/home/node/.openclaw/workspace",
        "agentDir": "/home/node/.openclaw/agents/ops/agent"
      },
      {
        "id": "cipher",
        "name": "Cipher",
        "workspace": "/home/node/.openclaw/workspace-cipher",
        "agentDir": "/home/node/.openclaw/agents/cipher/agent"
      }
    ]
  }

Cipher goes to agents/cipher/sessions no problem, but Ops goes to agents/main/sessions even though it isn't set to do so.

The channel I have configured is Discord - so that might help, since it could be that plugin causing this behaviour.

And in the official discord channel I have the thread #1491458068209471629 in the #help text channel. Where I was told I should mention #29683 and PR's: PR #30654, PR #57217.

fix options:

  • pass cfg into resolveSessionKey() and use resolveDefaultAgentId(cfg) instead of the hardcoded constant
  • wrap remaining resolveSessionKey() call sites with canonicalizeMainSessionAlias() (find with grep -r "resolveSessionKey(" extensions/ src/)

This next bit is TL;DR; but I'm putting it here as a summary from the discord thread just for completeness:

you're right — this is a real bug.

root cause:
resolveSessionKey() in src/config/sessions/session-key.ts hardcodes DEFAULT_AGENT_ID="main", ignoring your custom default agent. session keys are written incorrectly to ~/.openclaw/agents/main/sessions/ even when configured for ops.

existing partial fixes:
- PR #30654: wrapped 3 call sites but didn’t fix the core function
- PR #57217: only cleans up old orphaned keys, does not prevent new bad writes

why it still fails for you:
uncovered call sites (e.g., slack extension) still use the broken function directly.

help maintainers: share which channel you used (telegram/discord/slack/web/signal/mattermost)

how to file the bug:
1. github: https://github.com/openclaw/openclaw/issues/new (bug template)
2. title: session key write still hardcodes DEFAULT_AGENT_ID after PR #30654 (regression of #29683)
3. body: version, agents.list config snippet, channel, symptom, reference #29683, PR #30654, PR #57217

fix options:
- pass cfg into resolveSessionKey() and use resolveDefaultAgentId(cfg) instead of the hardcoded constant
- wrap remaining resolveSessionKey() call sites with canonicalizeMainSessionAlias() (find with grep -r "resolveSessionKey(" extensions/ src/)

tldr: i was wrong earlier — this is a real bug with an incomplete fix. please file the issue. ❤️

Steps to reproduce

  1. Start up OpenClaw 2026.4.8 using the docker image from github.
  2. Set up the initial agent. And use Discord as your channel.
  3. Add another agent.
  4. Stop the gateway.
  5. Go back and change the main from the original agent, and set it as default: true. 5.1) [optional] go through and update all references of main e.g. the initially set up folders, any sessions used so far, etc. so that it no longer says main:main or similar and instead uses the agentId you changed to.
  6. Make sure you don't have a folder ~/.openclaw/agents/main.
  7. Start the server back up.

You should see the ~/.openclaw/agents/main folder return (expected, since it is the default hardcoded agentId). But if you now talk to your renamed agent via Discord, you will find the agents/main/session folder will start filling up again. Your second agent will work as expected though.

Expected behavior

I expected when talking to my default agent (not set as main) to go to its relevant sessions folder, and not the main folder.

Actual behavior

When talking via Discord, the default agent sessions get stored in the main folder.

OpenClaw version

2026.4.8

Operating system

Debian 12.13 (bookworm) - its a docker image based on node:24-bookworm. Host that the docker is on is Ubuntu 24.04

Install method

docker compose using: ghcr.io/openclaw/openclaw

Model

kimi-for-coding/k2p5

Provider / routing chain

openclaw -> kimi-for-coding

Additional provider/model setup details

No response

Logs, screenshots, and evidence

There are no errors in logs, its only visible by looking at the folder within `~/.openclaw/agents/main/sessions` and monitoring it as you speak with the agent via Discord. It is possible this affects other channels too.

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

Passing the configuration into resolveSessionKey() and using resolveDefaultAgentId(cfg) instead of the hardcoded constant may fix the issue with sessions being stored in the wrong directory.

Guidance

  • Identify all call sites of resolveSessionKey() using grep -r "resolveSessionKey(" extensions/ src/ and wrap them with canonicalizeMainSessionAlias() to ensure correct session key resolution.
  • Consider passing the configuration into resolveSessionKey() to use the default agent ID from the configuration instead of the hardcoded "main" constant.
  • Verify that the agents.list[].sessionsDir is correctly set for each agent to ensure sessions are stored in the expected directory.
  • Test the fix by reproducing the issue and checking if sessions are now stored in the correct directory for the default agent.

Example

No code snippet is provided as the issue does not include sufficient information to create a specific example.

Notes

The provided fix options may not be exhaustive, and additional changes may be required to fully resolve the issue. The fact that there are no errors in the logs and the issue is only visible by monitoring the folder suggests that the problem may be related to the session key resolution logic.

Recommendation

Apply the workaround by passing the configuration into resolveSessionKey() and using resolveDefaultAgentId(cfg) instead of the hardcoded constant, as this is a more targeted fix for the identified root cause.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

I expected when talking to my default agent (not set as main) to go to its relevant sessions folder, and not the main folder.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING