Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix BUG: openclaw agent --session-id silently ignored when --agent is specified [1 pull requests, 1 comments, 2 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#60614•Fetched 2026-04-08 02:49:07
View on GitHub
Comments
1
Participants
2
Timeline
3
Reactions
0
Author
foreverxdordforeverxdord
Participants
foreverxdordforeverxdordliujiaqiidliujiaqiid
Timeline (top)
commented ×1cross-referenced ×1referenced ×1

openclaw agent --session-id <uuid> is silently ignored when --agent <id> is specified. The CLI always routes to the agent's main session, regardless of --session-id or --to values. This makes it impossible to route CLI-sent messages to non-main sessions (e.g., group chat sessions created via webhook).

Root Cause

openclaw agent --session-id <uuid> is silently ignored when --agent <id> is specified. The CLI always routes to the agent's main session, regardless of --session-id or --to values. This makes it impossible to route CLI-sent messages to non-main sessions (e.g., group chat sessions created via webhook).

Fix Action

Fix / Workaround

Gateway log confirms all CLI-routed messages go to the agent's main session:

2026-04-04T08:39:48.846+08:00 [feishu] feishu[default]: dispatching to agent (session=agent:alice:main)

Medium. Blocks programmatic routing to non-main sessions via CLI. Workaround available (route to main session only).

PR fix notes

PR #60621: fix: allow --session-id to override --agent in agent command (fixes #60614)

Description (problem / solution / changelog)

Summary

Fixes issue #60614 where openclaw agent --session-id <uuid> was silently ignored when --agent <id> was specified.

Root Cause

In src/agents/command/session.ts, the resolveSessionKeyForRequest function had a condition that prevented sessionId lookup when an agent was specified:

if (
  opts.sessionId &&
  !explicitSessionKey &&  // ← This blocked sessionId lookup when --agent was provided
  ...
)

When --agent was passed, explicitSessionKey was set from the agent's main session key, causing the sessionId lookup to be skipped entirely.

Fix

Removed the !explicitSessionKey condition to allow sessionId to take precedence over agentId. This enables explicit session targeting even when an agent is specified.

Testing

Added comprehensive test coverage in src/agents/command/session.test.ts:

  • Verifies sessionId takes precedence over agentId
  • Tests finding sessions in both primary and alternate agent stores
  • Validates fallback behavior when sessionId is not found

Impact

  • Users can now route CLI messages to specific sessions (e.g., group chat sessions) even when specifying an agent
  • No breaking changes - existing behavior is preserved when only --agent or only --session-id is used

Changed files

  • src/agents/command/session.test.ts (added, +154/-0)
  • src/agents/command/session.ts (modified, +4/-3)

Code Example

2026-04-04T08:39:48.846+08:00 [feishu] feishu[default]: dispatching to agent (session=agent:alice:main)

---

{
  "sessionId": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
  "sessionKey": "agent:main:main",
  "workspaceDir": "/home/user/.openclaw/workspace-main"
}
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

openclaw agent --session-id <uuid> is silently ignored when --agent <id> is specified. The CLI always routes to the agent's main session, regardless of --session-id or --to values. This makes it impossible to route CLI-sent messages to non-main sessions (e.g., group chat sessions created via webhook).

Steps to reproduce

  1. Configure an agent (e.g. myagent) in openclaw.json
  2. Create a group chat session via channel webhook (session key: agent:myagent:feishu:group:oc_xxx, session ID: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee)
  3. Run: openclaw agent --agent myagent --session-id aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee --message 'test' --deliver
  4. Observe: message appears in agent:myagent:main session, not the targeted group session

Expected behavior

Per docs at https://docs.openclaw.ai/tools/agent-send:

--session-id <id>: Use an explicit session id to reuse an existing session

--session-id should override --agent's default main session routing and deliver the message to the specified session.

Actual behavior

FlagsActual Session KeyExpected
--agent myagentagent:myagent:maincorrect
--agent myagent --session-id <uuid>agent:myagent:mainshould use session-id
--agent myagent --to 'chat:oc_xxx'agent:myagent:mainshould derive from --to
--session-id <uuid> (no --agent)agent:main:mainwrong agent config

OpenClaw version

2026.3.31

Operating system

macOS 26.2 (ARM64)

Install method

npm global

Model

glm-5-turbo (zai)

Provider / routing chain

zai -> glm-5-turbo

Additional provider/model setup details

Reproducible with any model/provider. The routing logic is independent of the LLM backend.

Logs, screenshots, and evidence

Gateway log confirms all CLI-routed messages go to the agent's main session:

2026-04-04T08:39:48.846+08:00 [feishu] feishu[default]: dispatching to agent (session=agent:alice:main)

--json output from --session-id (without --agent) confirms it falls back to the default main agent:

{
  "sessionId": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
  "sessionKey": "agent:main:main",
  "workspaceDir": "/home/user/.openclaw/workspace-main"
}

Impact and severity

Medium. Blocks programmatic routing to non-main sessions via CLI. Workaround available (route to main session only).

extent analysis

TL;DR

The issue can be worked around by omitting the --agent flag and using the --session-id flag alone to specify the target session.

Guidance

  • Verify that the --session-id flag is correctly formatted and matches the intended session ID.
  • Test omitting the --agent flag and using only the --session-id flag to route messages to non-main sessions.
  • Check the openclaw.json configuration to ensure the agent and session settings are correctly defined.
  • Use the --json output to confirm the session key and ID being used for routing.

Example

No code snippet is provided as the issue is related to command-line flag usage.

Notes

The issue seems to be related to the interaction between the --agent and --session-id flags. Omitting the --agent flag may allow the --session-id flag to correctly override the default main session routing.

Recommendation

Apply workaround: Omit the --agent flag and use the --session-id flag alone to route messages to non-main sessions, as this allows the correct session ID to be used for routing.

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

Per docs at https://docs.openclaw.ai/tools/agent-send:

--session-id <id>: Use an explicit session id to reuse an existing session

--session-id should override --agent's default main session routing and deliver the message to the specified session.

#container setup#orchestration issue#cache issue#memory leak#API versioning

Still need to ship something?

×6

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

Back to top recommendations

TRENDING