Problem

AceClaw already appears to support multiple concurrent CLI sessions against a single daemon, but the product surface and local scripts do not make that workflow explicit or safe.

Today this is confusing because:

• each CLI creates its own sessionId, but this is mostly implicit
• dev.sh currently restarts the daemon, which will interrupt any other open TUI sessions
• there is no clear non-destructive entrypoint for "open another TUI window on the current daemon"
• it is not obvious which state is session-local vs daemon-shared vs workspace-shared
• there is no guardrail preventing two TUI windows from attaching to the same workspace at the same time
• the docs do not yet describe the recommended multi-session workflow clearly enough

Why

A common workflow is:

• use dev.sh in one workspace to rebuild / restart during development
• keep that daemon running
• open one or more additional TUI windows, potentially in other workspaces, against the same daemon
• let each TUI get its own independent session while sharing the daemon process

That workflow is close to what the architecture already supports, but the current tooling makes it too easy to accidentally bounce the daemon and kill other live sessions, or to accidentally open duplicate TUI sessions for the same workspace.

Scope

• document the intended model: one daemon, many CLI/TUI clients, one session per CLI/TUI
• make the recommended startup flow explicit for multi-window and multi-workspace use
• upgrade the user/developer docs to explain dev.sh vs tui.sh, shared-daemon behavior, and same-workspace restrictions
• keep dev.sh as the development-oriented, potentially destructive script
• add a separate non-destructive TUI entrypoint that attaches to the existing daemon or starts one if missing
• show the current workspace clearly in status/startup surfaces
• prevent opening a second TUI for the same workspace when one is already active
• clarify the difference between session-local state and shared daemon/workspace state
• add lightweight UX/status affordances so users can tell which session they are in

Product Direction

Responsibility split should be explicit:

• dev.sh

  • for development work
  • may rebuild and restart the daemon
  • may run benchmark checks / baseline collection
  • is allowed to interrupt other sessions

• tui.sh (or equivalent)

  • for opening another interactive AceClaw window
  • must not restart or kill the shared daemon by default
  • should connect to the current daemon if it exists
  • should start a daemon only if none is running
  • should not run benchmark check / baseline steps
  • should refuse to open if another active TUI session already owns the same workspace

Possible Implementation Directions

• add docs for a recommended workflow such as: start/restart with dev.sh, then open additional TUI windows with tui.sh
• add tui.sh (or equivalent) as a non-destructive attach-or-start script
• surface the current workspace and current sessionId (or a short session label) in the status line and/or startup banner
• add a workspace-level active-session lock/check so tui.sh can detect an existing live TUI for the same workspace and abort with a clear message
• update usage docs / README / developer docs to explain the multi-session model and script responsibilities
• optionally add aceclaw daemon attach / aceclaw session new style UX later if needed

Acceptance Criteria

• users can intentionally run multiple CLI/TUI windows against one daemon without guessing
• opening another local TUI session does not restart or kill the shared daemon by default
• dev.sh remains clearly positioned as the development/restart script
• tui.sh (or equivalent) is clearly positioned as the non-destructive multi-session entrypoint
• the current workspace is visible in at least one always-available CLI status surface
• tui.sh refuses to open a second TUI for the same workspace and prints a clear explanation
• docs are updated to describe the multi-session workflow, the dev.sh vs tui.sh split, and same-workspace restrictions
• session-local vs shared state is documented clearly enough to avoid surprise
• at least one CLI-visible surface identifies the current session

Related

• feat: Dual-Channel Architecture — Multi-Connection Model for Background Tasks & Concurrent Input #48 dual-channel architecture
• Fix workspace consistency across CLI sessions with a shared daemon #98 shared-daemon workspace consistency
• Auto Resume: upgrade 'continue' to deterministic task-level restoration (final solution) #92 deterministic task-level resume
• feat(dev): auto-select benchmark mode in dev.sh based on changed files #330 dev.sh benchmark mode UX