Workspaces: chat sessions created from the CLI never show in the app #9037

Activity

1. github-actions commented on Oct 29, 2026

   

   github-actionsBot

   on Oct 29, 2026 – with GitHub Actions

   Contributor

   More actions

   The CLI side works: the session exists on the host and runs. The desktop app is the part that never shows it. In the current code, the app only adopts a host-side chat session, or focuses one from a sessionId deep link, when the experimental ACP chat feature is on. When it is off, both paths stop silently, which fits this report. I traced this by reading the code only and did not run anything. The app here is 1.40.0, so check that these paths look the same in that build.

   Summary

   Chat sessions created with superset sessions create --local show in superset sessions list (live: true, harness claude-acp) and their agents run. They never appear in the desktop app. superset sessions open and a superset://v2-workspace/<ws>?sessionId=<id> link both exit 0 and do nothing visible. Separately, superset status --json reports running: false, stale: true even though the host-service at that pid is alive and answering on the endpoint in its manifest.

   Affected code

   1. How the app finds a session: it is adopted on the host side, gated by ACP chat

   • The CLI only asks the host-service to create the session (packages/cli/src/commands/sessions/create/command.ts:42). It adds nothing to the desktop pane layout.
   • The app shows such a session only through useAutoAdoptChatSessions. While the workspace page is mounted, it lists host sessions and adds a chat-v3 tab for each live, unattached ACP session (apps/desktop/src/renderer/routes/_authenticated/_dashboard/v2-workspace/$workspaceId/hooks/useAutoAdoptChatSessions/useAutoAdoptChatSessions.ts:257-300).
   • That hook does nothing unless useAcpChatEnabled() returns "enabled" (useAutoAdoptChatSessions.ts:67-68).
   • useAcpChatEnabled returns "disabled" in two cases (apps/desktop/src/renderer/hooks/useAcpChatEnabled/useAcpChatEnabled.ts:8-14):
     • the PostHog flag FEATURE_FLAGS.ACP_CHAT is off for the user, or
     • the user turned the experiment off in Experimental settings (apps/desktop/src/renderer/stores/acp-chat.ts, persisted as acp-chat).
   • claude-acp does map to the claude preset (packages/chat/src/core/harness/harness.ts:10-16), so the harness is not the problem.

   2. The sessionId deep link is dropped silently under the same gate

   • useConsumeAutomationRunLink only fetches the session when acpChat === "enabled" (.../hooks/useConsumeAutomationRunLink/useConsumeAutomationRunLink.ts:59).
   • When chat is disabled, it removes sessionId from the URL and focuses nothing (useConsumeAutomationRunLink.ts:77-80). There is no toast and no log.
   • The CLI only spawns open <url> and returns as soon as that process starts (packages/cli/src/lib/open-url.ts:27-42). So it exits 0 no matter what the app does with the link.
   • The "no entry in main.log" detail is probably not a clue. processDeepLink logs with plain console.log (apps/desktop/src/main/index.ts:176). I found no electron-log console hookup in apps/desktop/src (log.initialize, log.functions), so that line probably never reaches main.log, even when the link is handled.

   3. superset status says "stale" for a host-service started by the desktop app (a separate bug that misleads debugging)

   • status calls verifyManifestOwner (packages/cli/src/commands/status/command.ts:69). That reads the command line from ps and accepts the process only if it contains superset-host (packages/cli/src/lib/host/process-identity.ts:3,25-27).
   • The desktop app does not start host-service that way. It runs host-service.js under the Electron binary (apps/desktop/src/main/lib/host-service-coordinator.ts:319), and its own tests show the command line as /Applications/Superset.app/Contents/MacOS/Superset /app/host-service.js (host-service-coordinator.test.ts:647).
   • So the CLI gets a readable command line without superset-host. It never tries the health-ping fallback (manifest-liveness.ts:27) and reports stale: true.
   • The desktop's own identity check matches on path.basename(this.scriptPath), i.e. host-service.js (host-service-coordinator.ts:1476). The CLI check is out of step with that.
   • sessions * commands are not affected: they use resolveHostTarget, which only checks that the pid is alive (packages/cli/src/lib/host-target/resolveHostTarget.ts:63). That is why sessions list works while status says stale.

   Suspected root cause

   • Most likely: ACP chat is effectively disabled in this desktop app, either because the acp-chat flag is off for this user or because the experimental toggle was turned off. With it off:
     • auto-adopt never runs, so CLI-created sessions get no tab;
     • the sessionId deep link is consumed and thrown away.
     • The CLI can create ACP sessions whatever the flag says, so it produces sessions this app will never show.
   • If chat is enabled, the remaining condition in the code is that the workspace page has to be open for adoption to happen. Nothing adopts sessions for workspaces that are not open.
   • The stale status: a false positive from the superset-host name match, explained in section 3. It is not why the sessions are missing.

   Reproduction

   1. Turn off Settings → Experimental → ACP chat (or use an account without the acp-chat flag).
   2. Run superset sessions create --local --workspace <ws> --agent claude --prompt hi.
   3. Open the workspace in the app: no chat tab appears.
   4. Run superset sessions open --local --workspace <ws> --session <id>: the window comes to the front, sessionId is removed from the URL, and nothing gets focus.
   5. Turn ACP chat back on and the session should be adopted as a tab within one refresh.

   For the reporter: check whether Settings → Experimental shows ACP chat as off. The acp-chat key in renderer localStorage holds enabled: false if it was turned off.

   Unit test sketches:

   • process-identity.test.ts: looksLikeHostProcess("/Applications/Superset.app/Contents/MacOS/Superset /app/host-service.js") returns false today, and should return true.
   • status/command.test.ts: give inspectCommand that command line with a live pid, and assert running: true (today it returns stale: true).

   Fix direction

   • CLI ↔ app gating:
     • Have sessions create / sessions open warn when the target app will not show ACP chats; host-service could report this.
     • Or, in useConsumeAutomationRunLink, when chat is disabled, show a toast ("Chat sessions are turned off in Settings → Experimental") instead of dropping sessionId silently.
     • Consider adopting sessions created outside the app even when the experiment toggle is off, as the acp-chat.ts comment already says automations and cloud workspaces do.
   • status false stale: make looksLikeHostProcess also accept host-service.js, like the desktop coordinator does. Alternatively, run the authenticated health probe before deciding a readable but non-matching command line means stale.
   • Logging: send processDeepLink's logs through electron-log so main.log records deep link handling.