OpenClaw bug report draft: Control UI / TUI session continuity disappears during normal use
Summary
OpenClaw local sessions intermittently disappear or become inaccessible during normal use.
This affects both:
The problem is not explained by a single bad local workflow. After isolating likely confounders, session continuity still appears unreliable enough to break normal conversation flow.
Environment
- Host: macOS (Darwin 25.1.0 arm64)
- OpenClaw installed via Homebrew/npm path under
/opt/homebrew/lib/node_modules/openclaw
- Gateway running locally on port
18789
- Dashboard/control UI accessed locally
- Common URL used during testing:
http://127.0.0.1:18789/
- Auth: token URL flow
Observed symptoms
- Existing chat/session disappears from Control UI session list or the active page loses continuity.
- TUI conversation continuity also appears to break, not just Control UI.
- Messages or follow-up interaction appear to vanish during/after tool execution or reconnect-like moments.
- Sending slash-style skill triggers from Control UI chat composer was unreliable in this state.
- Creating/switching sessions, reconnecting, or mixed-surface usage appears to increase the chance of losing continuity.
Reproduction pattern (not fully deterministic, but repeatedly observed)
- Open local dashboard / Control UI.
- Use the same environment across Control UI and/or TUI.
- Send normal messages, sometimes involving tools or longer-running work.
- Sometimes open a new session, switch sessions, or reconnect.
- After some interaction, the visible session/chat continuity disappears or becomes inaccessible.
What was ruled out / investigated
1. Token/session URL parsing mismatch suspicion
Local inspection showed the frontend parser accepts token, gatewayUrl, and session from URL search/hash.
A pinned URL mitigation was tested:
http://127.0.0.1:18789/#token=...&session=agent:main:main
Result:
- Brief improvement
- Not a full fix, session still disappeared later
2. Local skill installation issue
Graphify skill was confirmed installed correctly in the local user skill directory and includes trigger: /graphify.
So the continuity issue was not caused by the skill being absent.
3. OpenClaw cron interference
Relevant auto-nudge cron jobs were inspected and found disabled at time of investigation.
4. Separate macOS LaunchAgent interference
A separate LaunchAgent existed and was likely a confounder.
It was configured with:
RunAtLoad = true
StartInterval = 300
It repeatedly attempted to run an OpenClaw-related continuation script and logged repeated failures:
error: required option '-t, --target <dest>' not specified
This LaunchAgent was then explicitly disabled.
Even after identifying this as a likely amplifier/confounder, the broader session continuity issue still appeared credible.
Local evidence gathered
- Control UI frontend state/parser inspection in built assets under:
/opt/homebrew/lib/node_modules/openclaw/dist/control-ui/assets/
- Session/parser logic observed in built frontend asset bundle
- Pinned launcher created locally to force host + session
- Local repro notes and artifacts recorded during debugging
Why this seems like an upstream issue
The failure mode closely resembles existing issue classes already seen by users:
- session disappears from dropdown / becomes inaccessible
- previous chat becomes inaccessible after session change/new session
- content disappears during tool execution / heartbeat / reconnect-like transitions
- token/session instability across surfaces
The problem also affected more than one surface, which makes it less likely to be a simple one-page UI mistake.
Impact
This breaks confidence in OpenClaw as a stable live work surface for:
- multi-turn conversations
- long tool-assisted tasks
- switching between TUI and Control UI
- using the UI as a reliable audit trail of work already done
Users are forced to treat on-disk file outputs as the only trustworthy source of truth.
Requested help
Please help identify whether there is a current regression in:
- session persistence/storage
- cross-surface session synchronization
- reconnect/session restoration
- session selection/focus after tool runs or new sessions
If useful, I can provide more exact local state, config snippets, and additional reproduction traces privately in redacted form.
OpenClaw bug report draft: Control UI / TUI session continuity disappears during normal use
Summary
OpenClaw local sessions intermittently disappear or become inaccessible during normal use.
This affects both:
The problem is not explained by a single bad local workflow. After isolating likely confounders, session continuity still appears unreliable enough to break normal conversation flow.
Environment
/opt/homebrew/lib/node_modules/openclaw18789http://127.0.0.1:18789/Observed symptoms
Reproduction pattern (not fully deterministic, but repeatedly observed)
What was ruled out / investigated
1. Token/session URL parsing mismatch suspicion
Local inspection showed the frontend parser accepts
token,gatewayUrl, andsessionfrom URL search/hash.A pinned URL mitigation was tested:
http://127.0.0.1:18789/#token=...&session=agent:main:mainResult:
2. Local skill installation issue
Graphify skill was confirmed installed correctly in the local user skill directory and includes
trigger: /graphify.So the continuity issue was not caused by the skill being absent.
3. OpenClaw cron interference
Relevant auto-nudge cron jobs were inspected and found disabled at time of investigation.
4. Separate macOS LaunchAgent interference
A separate LaunchAgent existed and was likely a confounder.
It was configured with:
RunAtLoad = trueStartInterval = 300It repeatedly attempted to run an OpenClaw-related continuation script and logged repeated failures:
error: required option '-t, --target <dest>' not specifiedThis LaunchAgent was then explicitly disabled.
Even after identifying this as a likely amplifier/confounder, the broader session continuity issue still appeared credible.
Local evidence gathered
/opt/homebrew/lib/node_modules/openclaw/dist/control-ui/assets/Why this seems like an upstream issue
The failure mode closely resembles existing issue classes already seen by users:
The problem also affected more than one surface, which makes it less likely to be a simple one-page UI mistake.
Impact
This breaks confidence in OpenClaw as a stable live work surface for:
Users are forced to treat on-disk file outputs as the only trustworthy source of truth.
Requested help
Please help identify whether there is a current regression in:
If useful, I can provide more exact local state, config snippets, and additional reproduction traces privately in redacted form.