Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix sessions.create silently drops messages containing :// (2026.4.1+) [1 pull requests, 2 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#59887•Fetched 2026-04-08 02:39:15
View on GitHub
Comments
2
Participants
2
Timeline
5
Reactions
0
Author
wkeythingwkeything
Participants
neeravmakwananeeravmakwanawkeythingwkeything
Timeline (top)
commented ×2cross-referenced ×1subscribed ×1unsubscribed ×1

Fix Action

Fix / Workaround

Any sessions.create message containing :// (URLs, connection strings) causes the agent dispatch to silently fail. The session is created and status: "started" is returned, but the agent never runs — no hooks fire, no LLM call is made, the session transcript remains empty.

A failing session produces zero diagnostic output after sessions.create returns. The dispatchInboundMessage call appears to silently fail before any agent infrastructure is invoked.

PR fix notes

PR #59961: fix(gateway): persist sessions.create user turns

Description (problem / solution / changelog)

Summary

  • Problem: sessions.create could start an initial turn without persisting the accepted user message into the transcript.
  • Why it matters: session watchers and transcript readers could see only the session header, which matched the reported :// symptom and also affected plain messages.
  • What changed: gateway chat handling now appends the first accepted user turn to the transcript with a stable idempotency key and adds regression coverage for both plain text and URL-containing initial messages.
  • What did NOT change (scope boundary): model dispatch, message parsing, and the sessions.create wire contract stay the same.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #59887
  • Related #59887
  • This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

  • Root cause: the eager sessions.create/chat.send path only emitted a transcript-update event for the first user turn instead of appending that turn to the transcript file.
  • Missing detection / guardrail: the existing regression test only asserted runStarted and messageSeq, not that the initial user message was actually readable from the transcript.
  • Prior context (git blame, prior PR, issue, or refactor if known): the linked issue reported the symptom as URL-specific, but the current code path reproduces it for plain initial messages too.
  • Why this regressed now: the gateway relied on SessionManager.appendMessage() semantics indirectly without accounting for the library's no-flush-before-assistant behavior.
  • If unknown, what was ruled out: ruled out ://-specific parsing in sessions.create, chat.send, and the gateway CLI --params JSON path.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: src/gateway/server.sessions.gateway-server-sessions-a.test.ts
  • Scenario the test should lock in: sessions.create writes the initial user turn to the transcript for both plain text and URL-containing messages.
  • Why this is the smallest reliable guardrail: the bug is in the gateway-to-transcript seam, so the gateway harness test exercises the real session creation and transcript read path without broader runtime noise.
  • Existing test that already covers this (if any): none
  • If no new test is added, why not: N/A

User-visible / Behavior Changes

  • sessions.create now makes the initial accepted user turn visible in transcript/history readers immediately.
  • Messages containing URLs like https://example.com now persist through the same path instead of appearing to vanish from the transcript.

Diagram (if applicable)

Before:
[sessions.create initial message] -> [session starts] -> [transcript update event only] -> [transcript file missing user turn]

After:
[sessions.create initial message] -> [session starts] -> [user turn appended to transcript] -> [watchers/history see user turn]

Security Impact (required)

  • New permissions/capabilities? (Yes/No) No
  • Secrets/tokens handling changed? (Yes/No) No
  • New/changed network calls? (Yes/No) No
  • Command/tool execution surface changed? (Yes/No) No
  • Data access scope changed? (Yes/No) No
  • If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

  • OS: macOS (darwin 25.3.0)
  • Runtime/container: Node.js / pnpm local repo checkout
  • Model/provider: N/A for the regression check
  • Integration/channel (if any): Gateway sessions.create
  • Relevant config (redacted): default gateway test harness session store

Steps

  1. Create a session with sessions.create and include an initial message or task.
  2. Read the created transcript immediately.
  3. Compare the transcript contents for plain text and https://... messages.

Expected

  • The transcript contains the first user turn.

Actual

  • Before this fix, the transcript could contain only the session header even though the run started.

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

  • Verified scenarios:
    • pnpm test -- src/gateway/server.sessions.gateway-server-sessions-a.test.ts
    • pnpm build
    • Added and passed regression checks for both task: "hello from create" and message: "visit https://example.com" through sessions.create
  • Edge cases checked:
    • first-turn transcript persistence before any assistant reply exists
    • URL-containing initial message
    • idempotent append keyed by the gateway run id
  • What you did not verify:
    • A fully green local pnpm check and pnpm test run was not possible because of unrelated existing failures in extensions/diffs/src/language-hints.test.ts and src/tts/status-config.test.ts

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? (Yes/No) Yes
  • Config/env changes? (Yes/No) No
  • Migration needed? (Yes/No) No
  • If yes, exact upgrade steps: N/A

Risks and Mitigations

  • Risk: the fix uses a targeted forced transcript rewrite for pre-assistant sessions because the underlying session manager does not flush user-only sessions eagerly.
    • Mitigation: the rewrite is limited to transcripts with no assistant turn yet, and the gateway regression test now covers both plain and URL-containing initial messages.

Additional Notes

  • AI assistance: prepared with a coding agent and manually reviewed/verified before opening.

Made with Cursor

Changed files

  • src/gateway/server-methods/chat.ts (modified, +103/-7)
  • src/gateway/server.sessions.gateway-server-sessions-a.test.ts (modified, +97/-2)

Code Example

# Start mock LLM on port 18765
# Start gateway with mock provider pointing to it

# This works:
openclaw gateway call sessions.create \
  --expect-final --timeout 10000 --json \
  --url ws://127.0.0.1:19500 --token t \
  --params '{"key":"test-plain","message":"hello world"}'
# → Session has 6 lines (session header + user message + LLM response)

# This fails silently:
openclaw gateway call sessions.create \
  --expect-final --timeout 10000 --json \
  --url ws://127.0.0.1:19500 --token t \
  --params '{"key":"test-url","message":"visit https://example.com"}'
# → Session has 1 line (session header only, empty)

---

preflightCompaction → memoryFlush → lane enqueue → lane dequeue →
embedded run start → before_prompt_build → run agent start → run agent end →
session state: processing → idle → run cleared → run done
RAW_BUFFERClick to expand / collapse

Bug

Any sessions.create message containing :// (URLs, connection strings) causes the agent dispatch to silently fail. The session is created and status: "started" is returned, but the agent never runs — no hooks fire, no LLM call is made, the session transcript remains empty.

Verified on 2026.4.1 and 2026.4.2. Works correctly on 2026.3.28.

Reproduction

Bare OpenClaw, no plugins, no intercepts, working mock LLM:

# Start mock LLM on port 18765
# Start gateway with mock provider pointing to it

# This works:
openclaw gateway call sessions.create \
  --expect-final --timeout 10000 --json \
  --url ws://127.0.0.1:19500 --token t \
  --params '{"key":"test-plain","message":"hello world"}'
# → Session has 6 lines (session header + user message + LLM response)

# This fails silently:
openclaw gateway call sessions.create \
  --expect-final --timeout 10000 --json \
  --url ws://127.0.0.1:19500 --token t \
  --params '{"key":"test-url","message":"visit https://example.com"}'
# → Session has 1 line (session header only, empty)

Affected patterns

Message contentResult
hello world✅ Works
example.com (bare)✅ Works
10.0.0.1:5432✅ Works
[email protected]✅ Works
https://example.com❌ Silent fail
http://example.com❌ Silent fail
postgresql://host/db❌ Silent fail
mysql://host/db❌ Silent fail
mongodb://host/db❌ Silent fail

The pattern: any message containing :// triggers the failure.

Verbose gateway analysis

With --verbose, a working session produces full diagnostic output:

preflightCompaction → memoryFlush → lane enqueue → lane dequeue →
embedded run start → before_prompt_build → run agent start → run agent end →
session state: processing → idle → run cleared → run done

A failing session produces zero diagnostic output after sessions.create returns. The dispatchInboundMessage call appears to silently fail before any agent infrastructure is invoked.

Not network-related

Tested with:

  • Default bridge network (full internet access)
  • /etc/hosts entries for all domains
  • iptables DNAT rules

The bug occurs regardless of network configuration.

Environment

  • OpenClaw 2026.4.1 (da64a97) and 2026.4.2
  • Node.js v22.22.2
  • Ubuntu / Docker (node:22-slim)
  • No plugins installed

Impact

This is a showstopper for any plugin or agent that processes user messages containing URLs or connection strings — which is essentially all real-world usage.

We've confirmed this affects our plugin (shroud-privacy) but the bug is in OC core — reproduced on bare OC without any plugins.

extent analysis

TL;DR

The issue can be worked around by modifying the message to avoid containing :// or by preprocessing the message to escape or remove this pattern before creating a session.

Guidance

  • Verify that the issue is indeed caused by the presence of :// in the message by testing with different messages that do and do not contain this pattern.
  • Consider preprocessing the message to remove or escape :// before passing it to sessions.create, to prevent the silent failure.
  • Review the OpenClaw documentation and source code to see if there are any configuration options or hooks that can be used to customize the handling of messages containing ://.
  • Test the issue with different versions of OpenClaw to confirm that it is specific to versions 2026.4.1 and 2026.4.2.

Example

# Preprocess the message to remove '://'
openclaw gateway call sessions.create \
  --expect-final --timeout 10000 --json \
  --url ws://127.0.0.1:19500 --token t \
  --params '{"key":"test-url","message":"visit https://example.com".replace("://", "/")}'

Notes

The root cause of the issue is not explicitly stated, but it appears to be related to the handling of messages containing :// in the OpenClaw core. The issue may be specific to certain configurations or environments.

Recommendation

Apply a workaround, such as preprocessing the message to remove or escape ://, until a fixed version of OpenClaw is available. This will allow plugins and agents that process user messages containing URLs or connection strings to function correctly.

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…
#LLM response#authentication issue#prompt issue#agent setup#task chaining

Still need to ship something?

×6

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

Back to top recommendations

TRENDING