openclaw - 💡(How to fix) Fix WebChat fresh session shows only injected "New session started" bubble and skips actual startup greeting [1 comments, 2 participants]

Summary

In WebChat / Control UI, a fresh session can surface only the injected confirmation bubble:

✅ New session started.

and not trigger the expected first-turn startup greeting from the agent.

From the user's perspective, it looks like the assistant stopped greeting them, or that the first input was partially lost.

The transcript/log evidence shows that the confirmation bubble is written as a synthetic assistant message with:

• provider: "openclaw"
• model: "gateway-injected"
• zero token usage

while the actual model is only invoked on the next user message.

Why this looks wrong

The built-in bare reset prompt says:

A new session was started via /new or /reset. Execute your Session Startup sequence now ... Then greet the user in your configured persona ...

So for a fresh session, the expected behavior is:

1. session reset/new is acknowledged
2. agent startup sequence runs
3. user gets a real greeting / ready signal from the agent

What actually happens in this failure mode is:

1. WebChat shows ✅ New session started.
2. no model run happens for the greeting
3. the first real model run happens only after the next visible user message

This makes the startup UX ambiguous and can be misread as dropped input or a dead assistant.

Environment

• OpenClaw: 2026.4.29 (a448042)
• Gateway runtime observed in trajectory metadata: 2026.4.29, git sha 3866d42
• Channel: WebChat / Control UI direct chat
• Model: openai-codex/gpt-5.4
• Host OS: Linux 6.8.0-110-generic

Reproduction (observed)

1. Open a WebChat / Control UI direct conversation.
2. Trigger a fresh session (either explicitly or via whichever UI path currently starts/rotates the WebChat main session).
3. Observe the visible first assistant bubble.
4. Instead of a real assistant greeting, the chat shows only:
   • ✅ New session started.
5. Send a normal user message.
6. Only now does the actual model run and reply.

Expected behavior

After a fresh session starts in WebChat:

• either the agent should immediately produce the startup greeting promised by the bare reset prompt,
• or the UI should clearly distinguish a transport/session-control acknowledgement from the assistant's first conversational turn.

At minimum, users should not be left with a synthetic assistant bubble that looks like the assistant already responded when no agent run has occurred.

Actual behavior

The transcript begins with a synthetic assistant message:

{
  "role": "assistant",
  "content": [{ "type": "text", "text": "✅ New session started." }],
  "provider": "openclaw",
  "model": "gateway-injected",
  "usage": {
    "input": 0,
    "output": 0,
    "cacheRead": 0,
    "cacheWrite": 0,
    "totalTokens": 0
  }
}

Only the next user message triggers a normal model run.

Evidence from local logs

Observed trajectory/session:

• session id: 519d1770-787c-47c2-a1f7-02c11d49c886
• session key: agent:main:main

Trajectory shows the first real prompt submitted to the model was not a startup greeting trigger but the user's later question:

{"type":"prompt.submitted","data":{"prompt":"[Fri 2026-05-01 02:39 GMT+3] почему твое приветствие стало выглядеть так?"}}

The prior visible assistant bubble in that same session was injected, not model-generated:

{
  "role": "assistant",
  "content": [{ "type": "text", "text": "✅ New session started." }],
  "api": "openai-responses",
  "provider": "openclaw",
  "model": "gateway-injected",
  "usage": {
    "input": 0,
    "output": 0,
    "cacheRead": 0,
    "cacheWrite": 0,
    "totalTokens": 0,
    "cost": { "total": 0 }
  }
}

Likely root-cause area

Installed dist strongly suggests the session-control command path is returning the injected confirmation and then stopping when there is no reset tail:

dist/commands.runtime-*.js

if (!resetTail) return {
  shouldContinue: false,
  ...hookResult.routedReply ? {} : { reply: { text: commandAction === "reset" ? "✅ Session reset." : "✅ New session started." } }
};

And the confirmation is persisted as a transcript-only assistant message in:

dist/chat-*.js

provider: "openclaw",
model: "gateway-injected",
usage: { input: 0, output: 0, ... }

Separately, the startup prompt still claims the agent should greet after /new / /reset:

dist/startup-context-*.js

const BARE_SESSION_RESET_PROMPT_BASE = "A new session was started via /new or /reset. Execute your Session Startup sequence now ... Then greet the user ..."

So there appears to be a behavioral mismatch:

• reset command path emits a synthetic confirmation and stops
• startup prompt promises an immediate greeting

User impact

This is more than cosmetic:

• users think the assistant stopped greeting them
• users may think the first input was dropped
• the synthetic bubble looks like a real assistant reply even though no model run happened
• it becomes harder to tell whether the session is ready, broken, or waiting for another message

Suggested fixes

Any of these would be materially better:

1. Actually run the startup greeting after /new / /reset in WebChat, instead of stopping after the injected confirmation.
2. If the product intentionally does not want an automatic first-turn greeting, then:
   • stop promising it in BARE_SESSION_RESET_PROMPT_BASE, and/or
   • render the confirmation as a non-assistant system event, not as an assistant bubble in transcript/chat history.
3. Preserve a clear audit distinction in the UI between:
   • system/session-control acknowledgement
   • real model-generated assistant response

Related issues

Potentially related, but not identical:

• #45501 session.resetPrompt — configurable session startup message
• #63295 bare /new / /reset prompt drops sender envelope
• #70330 WebChat can silently rotate agent:main:main after restart/reconnect
• #75235 session reset currently leaves only ✅ New session started. with no real agent-side ready signal

Minimal acceptance test

For a fresh WebChat session:

1. trigger new/reset
2. verify whether the next visible item is:
   • a system event only, plus a real assistant greeting, or
   • a single real assistant greeting
3. verify the first assistant-looking bubble in transcript is not gateway-injected unless intentionally rendered as a separate system event
4. verify the agent does not require a second user message before producing its first conversational turn