Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: TUI /new stopped emitting hook-visible new-session behavior after 46008178d [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#49918•Fetched 2026-04-08 01:01:16
View on GitHub
Comments
1
Participants
2
Timeline
10
Reactions
1
Author
LonExplorer-coderLonExplorer-coder
Participants
Hollychou924Hollychou924LonExplorer-coderLonExplorer-coder
Timeline (top)
referenced ×4cross-referenced ×2labeled ×2commented ×1

After upgrading to 2026.3.7+, TUI /new no longer emits hook-visible new-session behavior because it switched from
resetSession(...) to local setSession(uniqueKey).

Root Cause

After upgrading to 2026.3.7+, TUI /new no longer emits hook-visible new-session behavior because it switched from
resetSession(...) to local setSession(uniqueKey).

Fix Action

Fixed

PR fix notes

PR #49945: TUI: restore hook-visible /new resets

Description (problem / solution / changelog)

Summary

Describe the problem and fix in 2–5 bullets:

  • Problem: #49918 reported that TUI /new stopped emitting hook-visible command:new behavior after the per-client session isolation change.
  • Why it matters: hook-driven flows like command-logger and session-memory silently stop running for TUI /new, even though users still expect a normal fresh-session reset.
  • What changed: /new now resets the newly allocated per-client tui-<uuid> session through sessions.reset(reason="new") before switching the TUI to that unique key, and the command-handler test now locks that route in.
  • What did NOT change (scope boundary): /reset behavior stays in-place on the current session, and TUI session isolation still uses unique per-client keys.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor
  • 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 #49918
  • Related #

User-visible / Behavior Changes

TUI /new once again emits the same hook-visible reset path as other reset flows, while still creating an isolated tui-<uuid> session for the current TUI client.

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:

Repro + Verification

Environment

  • OS: macOS
  • Runtime/container: Node 22 + pnpm + Vitest
  • Model/provider: N/A
  • Integration/channel (if any): TUI command handling + gateway session reset hooks
  • Relevant config (redacted): test harness defaults

Steps

  1. Register a hook that listens for command:new.
  2. Open openclaw tui and run /new.
  3. Observe whether the fresh-session path goes through sessions.reset(reason="new") or only switches local session state.

Expected

  • /new keeps the isolated tui-<uuid> behavior and still emits the standard hook-visible command:new reset path.

Actual

  • Before this patch, /new only called local setSession(uniqueKey) and skipped the gateway reset path entirely.

Evidence

Attach at least one:

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

Verification commands run locally:

  • pnpm test -- src/tui/tui-command-handlers.test.ts
  • pnpm test -- src/gateway/server.sessions.gateway-server-sessions-a.test.ts -t 'sessions.reset emits internal command hook with reason'
  • pnpm exec oxfmt --check src/tui/tui-command-handlers.ts src/tui/tui-command-handlers.test.ts
  • pnpm exec oxlint src/tui/tui-command-handlers.ts src/tui/tui-command-handlers.test.ts

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios: /new now routes through gateway reset with reason new, /reset still resets the shared current session, and existing gateway coverage still confirms that sessions.reset(reason="new") emits the internal command hook.
  • Edge cases checked: canonical agent:main:tui-<uuid> session key generation for /new and preserved /reset behavior.
  • What you did not verify: a live interactive TUI session with a real installed hook script.

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.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

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

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly: revert commit 37d84d03f8
  • Files/config to restore: src/tui/tui-command-handlers.ts, src/tui/tui-command-handlers.test.ts, CHANGELOG.md
  • Known bad symptoms reviewers should watch for: /new no longer emitting hook-visible resets, or TUI /new falling back to the shared main session instead of a unique tui-<uuid> key

Risks and Mitigations

List only real risks for this PR. Add/remove entries as needed. If none, write None.

  • Risk: /new could accidentally stop isolating the TUI client if the canonical unique key routing regresses.
    • Mitigation: the command-handler test asserts both the unique tui-<uuid> session handoff and the gateway reset call shape.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/gateway/protocol/schema/sessions.ts (modified, +1/-0)
  • src/gateway/server-methods/sessions.ts (modified, +1/-0)
  • src/gateway/server.sessions.gateway-server-sessions-a.test.ts (modified, +29/-0)
  • src/gateway/session-reset-service.ts (modified, +9/-2)
  • src/tui/gateway-chat.ts (modified, +2/-1)
  • src/tui/tui-command-handlers.test.ts (modified, +18/-7)
  • src/tui/tui-command-handlers.ts (modified, +3/-1)

Code Example

- Exact regression commit:                                                                                                
 - 46008178d1bab4a9cbb8ea270468b0f370cec370                                                                                
 - fix: isolate TUI /new sessions per client                                                                               
 - Version boundary verified by unpacking published npm releases:                                                          
 - 2026.3.2 → TUI /new still uses resetSession(...)                                                                        
 - 2026.3.7 → TUI /new uses setSession(uniqueKey)                                                                          
 - Current TUI code path:                                                                                                  
 - /new → const uniqueKey = \tui-${randomUUID()}`; await setSession(uniqueKey)`                                            
 - /reset → await client.resetSession(state.curren tSessionKey, name)
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Summary

After upgrading to 2026.3.7+, TUI /new no longer emits hook-visible new-session behavior because it switched from
resetSession(...) to local setSession(uniqueKey).

Steps to reproduce

  1. Enable a hook that depends on TUI new-session observability (for example command:new, session-memory, or
    command-logger).
  2. Restart OpenClaw and confirm the hook is registered.
  3. Start openclaw tui.
  4. Run /new.
  5. Observe that a new tui-<uuid> session is created, but no hook-visible new-session event is emitted.

Expected behavior

TUI /new should still emit a hook-visible new-session event, even if it keeps the isolated per-client tui-<uuid> session
behavior.

Actual behavior

TUI /new only switches to a new local session key via setSession(uniqueKey), so hook-based automation does not run.

OpenClaw version

2026.3.13

Operating system

macOS 15.3+ （Darwin 25.3.0 arm64）

Install method

npm global

Model

openai-codex/gpt-5.4

Provider / routing chain

openclaw -> configured default provider route

Config file / key location

~/.openclaw/openclaw.json

Additional provider/model setup details

This bug does not appear to depend on provider routing. It reproduces in TUI command handling before model/provider
choice matters.

Logs, screenshots, and evidence

- Exact regression commit:                                                                                                
 - 46008178d1bab4a9cbb8ea270468b0f370cec370                                                                                
 - fix: isolate TUI /new sessions per client                                                                               
 - Version boundary verified by unpacking published npm releases:                                                          
 - 2026.3.2 → TUI /new still uses resetSession(...)                                                                        
 - 2026.3.7 → TUI /new uses setSession(uniqueKey)                                                                          
 - Current TUI code path:                                                                                                  
 - /new → const uniqueKey = \tui-${randomUUID()}`; await setSession(uniqueKey)`                                            
 - /reset → await client.resetSession(state.curren tSessionKey, name)

Impact and severity

Affected: TUI users relying on hook-based new-session automation
Severity: Medium to High
Frequency: 100% repro
Consequence: command:new hooks, session-memory, command-logger, and custom workspace automation no longer run from TUI
/new

Additional information

This is a regression caused by commit 46008178d1bab4a9cbb8ea270468b0f370cec370.

Last known good: 2026.3.2
First known bad: 2026.3.7

The isolation change makes sense, but it removed the gateway-visible path that hooks relied on. A fix could keep isolated tui-<uuid> sessions while still emitting a standard internal event for TUI /new.

extent analysis

Fix Plan

To fix the regression, we need to modify the TUI /new command to emit a hook-visible new-session event while keeping the isolated per-client tui-<uuid> session behavior.

Here are the steps:

  • Modify the /new command to emit a new-session event after setting the new session key.
  • Update the setSession function to accept an optional emitEvent parameter.
  • Use the emitEvent parameter to emit the new-session event when setting the new session key.

Example code:

// Update the setSession function to accept an optional emitEvent parameter
async function setSession(uniqueKey, emitEvent = false) {
  // ... existing code ...
  if (emitEvent) {
    // Emit the new-session event
    await emitEvent('new-session', uniqueKey);
  }
}

// Modify the /new command to emit the new-session event
const uniqueKey = `tui-${randomUUID()}`;
await setSession(uniqueKey, true);

Alternatively, you can create a new function createNewSession that sets the new session key and emits the new-session event:

async function createNewSession() {
  const uniqueKey = `tui-${randomUUID()}`;
  await setSession(uniqueKey);
  await emitEvent('new-session', uniqueKey);
}

// Modify the /new command to use the createNewSession function
await createNewSession();

Verification

To verify that the fix worked, follow these steps:

  • Enable a hook that depends on the new-session event.
  • Restart OpenClaw and confirm the hook is registered.
  • Start OpenClaw TUI and run the /new command.
  • Observe that the hook is triggered and the new-session event is emitted.

Extra Tips

  • Make sure to update the documentation to reflect the changes to the setSession function and the /new command.
  • Consider adding tests to ensure that the new-session event is emitted correctly.
  • If you're using a version control system, make sure to commit the changes with a clear and descriptive message.

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

TUI /new should still emit a hook-visible new-session event, even if it keeps the isolated per-client tui-<uuid> session
behavior.

#api#ssr#installation#tensor shape#autograd error#agent setup#task chaining#parallel task#integration issue#index setup

Still need to ship something?

×6

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

Back to top recommendations

TRENDING