Superset Updates & Release Notes

TL;DR

• Less memory, fewer crashes. Sessions with lots of terminals stay responsive and are far less likely to white-screen, even on 8 or 16 GB machines.

Renderer memory 1,127 → 838 MB (−26%), JS heap 581 → 286 MB (−51%), 4× fewer GPU contexts.

• No more hitching from git. Switching branches or changing lots of files at once no longer stutters the app.

Worst-case stall on the UI thread 82.3 → 28.0 ms (3× smaller), typical 24.5 → 9.5 ms.

• Quieter in the background. Port detection uses far less CPU, so quieter fans and better battery, even with many terminals open.

Background scans 15 → 1 per cycle (15× fewer), idle terminals scan every 30s instead of every 2.5s (12× less).

Lower Memory When You Keep Many Terminals Open

Every hidden terminal used to keep its full scrollback and a live GPU context, forever. Open a lot of them in one session and memory could climb past a gigabyte.

Now Superset keeps only your most-recent terminals in memory. The rest are saved to disk and rebuilt when you switch back. The process behind each one keeps running the whole time, so nothing is lost.

The test: 16 background terminals, each filled with about 5,000 lines.

Metric Before After Terminals held in memory (GPU contexts) 16 4 Scrollback lines retained 80,016 20,004 Renderer JS heap 581 MB 286 MB (−51%) Renderer process memory (RSS) 1,127 MB 838 MB (−26%)

Renderer memory with 16 terminals open drops from 1,127 MB to 838 MB, a 26% reduction

Live GPU contexts held in memory drop from 16 to 4 with 16 terminals open, 4 times fewer

You set the limit in Settings → Terminal → Background terminal memory (default 12).

Active terminals are never touched. Neither are running TUIs like vim or a coding agent. Hidden in-app browser tabs get the same treatment.

Smoother While Git Churns in Big Repos

In big repos, git status used to run on the same thread that streams your terminal output. So a branch switch, or a burst of file changes across several workspaces, could make the whole app hitch.

That work now runs on a background pool of workers. Large batches of file-change events are capped instead of piling up.

The test: 8 workspaces churning a 20,000-file repo, with 600 files dirty.

Metric Before After File-watch stall, p99 31.7 ms 10.7 ms File-watch stall, worst case 82.3 ms 28.0 ms Full status refresh, p99 24.5 ms 9.5 ms Full status refresh, worst case 49.0 ms 17.6 ms

Worst-case main-thread stall under heavy git load drops from 82.3 ms to 28.0 ms

Typical main-thread stall (p99) under heavy git load drops from 24.5 ms to 9.5 ms

Lower is better here. It means the thread that keeps your terminals and UI responsive spends far less time blocked.

There's no setting to flip. It's on for everyone.

Lighter Background CPU From Port Detection

Port detection spots a dev server and offers to open it. It used to scan the whole process table once per terminal, on every tick. The more terminals you had open, the more background ps processes it spawned.

Now it runs one shared scan per cycle, no matter how many terminals are open. Idle terminals scan even less often.

The test: the real scanner with 15 terminals registered, counting every ps spawn over 6 cycles.

Metric Before After ps spawns per cycle 15 1 Total ps spawns over 6 cycles 90 6

Port detection with 15 terminals open drops from 15 background process scans per cycle to 1

Idle terminals scan every 30 seconds instead of every 2.5 seconds, 12 times less often

Idle terminals also slow down, from a scan every 2.5 seconds to every 30. They speed back up the moment they print output. So a machine full of quiet terminals nearly stops scanning.

Original source

Rich Input for the Terminal #5453

Rich Input for the Terminal

Press ⌘I over any terminal pane and compose in a real editor instead of the raw TTY line. Great for prompting CLI agents like Claude Code, Codex, and OpenCode.

• Enter sends, Shift+Enter adds a newline, and multiline prompts land as one block instead of executing line-by-line
• @file mentions work, powered by the same editor as workspace chat
• One global toggle covers every pane and persists across restarts

Terminal Scrolling at Ghostty Speed #5563

Terminal Scrolling at Ghostty Speed

Claude Code transcript scrolling in Superset terminals used to crawl at about a third of native speed. Agent TUIs now compensate correctly for our terminal, and scrolling matches Ghostty.

Mistral Vibe Joins the Agent Roster #5552

Mistral Vibe Joins the Agent Roster

Mistral Vibe is now a first-class terminal agent, contributed by @ThomsenDrake from the Mistral team. Pick it in any agent picker, choose a model, and get the same working indicator and completion chime as the built-ins.

• Model picker includes mistral-medium-3.5 and devstral-small
• GPT-5.6 Sol, Terra, and Luna added to the Codex model picker

Improvements

• Wake offline hosts - Attach a wake command to any host and run superset hosts wake to power it back on
• Remote hosts on every plan - Connecting to remote hosts through the relay no longer requires a paid plan
• Sydney relay region - Australian users get a local relay for lower latency and fewer dropped connections
• Inline update pill - The update toast is gone; a compact pill in the sidebar shows download progress, installs on click, and confirms the new version
• Copy CI logs - Copy a failed GitHub Actions job's logs straight from the review sidebar for pasting into a prompt
• Linear filters for Tasks - Filter and sort tasks by Linear project, cycle, due date, and priority across the desktop, CLI, and MCP
• Clear terminal connection errors - When a terminal can't connect, the pane now says why (host offline, no access, or a relay routing issue)
• Delete hosts - Owners can remove a host from Settings with typed confirmation
• Presets bar in the View menu - Show or hide the presets bar from View → Toggle Presets Bar
• CLI workspace lookup - superset ws get prints a workspace's details, with --field for scripting
• The main workspace is "local" - The repo checkout always displays as "local" and can no longer be renamed

Experimental: live agent sessions on iOS - an early build of driving a coding agent running on your desktop from the iOS app; the agent and your code stay on your machine. Off by default under Desktop → Settings → Security.

Bug fixes

• Fixed remote-host terminals showing "disconnected" when the host lives in a different relay region
• Stopped broken sessions from hammering auth endpoints with retry storms
• Diff view syntax highlighting now follows your custom theme
• Custom agent icons now apply to terminal presets
• Malformed pane layouts heal themselves instead of crashing the workspace
• Capped renderer memory growth from long chat sessions
• Workspaces now stay in the creating state until creation fully resolves
• Fixed agent launch failing when attachment directories were missing
• Fixed git status failing under a truncated login-shell PATH
• More reliable AI-generated workspace names
• Stopped sync clients from retrying fatal errors in a loop
• Terminal streams now close cleanly with accurate error codes instead of hanging

Original source

Adds a View → Toggle Presets Bar menu item that shows/hides the presets bar in both v1 and v2 workspace views (previously only reachable via the in-bar gear menu / Add Tab dropdown).

In v2, hiding the presets bar now hides the whole strip: the run script button relocates into the TopBar via a portal slot instead of leaving a slim stub bar behind.

Extracts two shared helpers along the way: useShowPresetsBar (v1 optimistic setting mutation, previously copy-pasted in PresetsBar and GroupStrip) and useSlotElement (portal slot lookup, previously inlined for the right sidebar).

Why / Context:

The presets bar visibility toggle only lived inside the bar itself and the Add Tab dropdown. A View menu entry is the conventional macOS home for chrome show/hide toggles. Separately, v2's "hidden" state wasn't really hidden — it kept a dedicated row just for the run button.

How It Works:

• main/lib/menu.ts adds the View item, which emits toggle-presets-bar on the existing menuEmitter; the menu.subscribe tRPC observable forwards it to the renderer (same path as Open Repo / Settings).
• V1: ContentView subscribes and flips the SQLite showPresetsBar setting through useShowPresetsBar, which reads the current value from the query cache so the toggle never acts on a stale closure.
• V2: the listener lives in v2-workspace/layout.tsx, deliberately above WorkspaceProvider. workspaceTrpc.Provider (nested inside it) shares @trpc/react-query's default React context, so electronTrpc hooks below it silently resolve the host-service httpBatchStreamLink client — which throws on subscriptions. A code comment documents this constraint.
• Run button relocation: TopBar renders an empty slot div on v2 workspace routes (empty:hidden avoids a phantom flex gap). When the presets bar is hidden, the v2 page portals the run button into it, keeping the button's React ownership (pane store, launcher, workspace providers) inside the page tree while the DOM lands in the TopBar.

Manual QA Checklist:

• View → Toggle Presets Bar hides/shows the bar in a v1 workspace
• View → Toggle Presets Bar hides/shows the bar in a v2 workspace
• Toggling on the dashboard (no workspace open) is a no-op, no errors
• Existing gear-menu / Add Tab dropdown checkboxes still work and stay in sync
• Hiding the presets bar removes the entire strip (no stub row)
• Run button appears in the TopBar (left of Open In) while hidden, and works
• Showing the bar again returns the run button to the bar's trailing edge
• Run button styling looks correct against the TopBar height (incomplete)
• RUN_WORKSPACE_COMMAND hotkey works in both states
• v1 and v2 visibility each persist across app restart (independent stores, pre-existing behavior)

Testing:

• bun run typecheck
• bun run lint
• Manual testing in dev mode (v1 + v2 workspaces)

Design Decisions:

• Plain toggle item instead of a checked menu item: a checkbox would require main-process knowledge of renderer state (two divergent stores, v1 SQLite vs v2 local prefs) plus menu rebuilds on every change. The plain item needs no sync and can't drift.
• Per-view listeners instead of one global handler: only the active workspace route is mounted, so each view flips exactly its own store; a global handler would need route sniffing to pick the store.
• Portal for the run button instead of rendering it in TopBar: the button needs useV2WorkspaceRun state that only exists inside the workspace page's provider tree; TopBar is outside it.

Known Limitations:

• The @trpc/react-query shared-default-context footgun remains: any electronTrpc hook used under workspaceTrpc.Provider silently talks to the host-service client. Giving electronTrpc a dedicated context (context: createContext(null)) would eliminate the bug class — deferred as a follow-up since it changes plumbing app-wide.

Summary by cubic:

Adds a View → Toggle Presets Bar for v1 and v2 workspaces. In v2, hiding the bar removes the strip and portals the run button into the TopBar; toggles read state at call time and handle rapid events correctly.

Summary by CodeRabbit:

New Features:

• Added a Toggle Presets Bar option to the desktop View menu.
• Presets bar visibility can now be toggled from the menu and stays synced with the workspace UI.
• Updated the v2 workspace layout so the run-button area adjusts when the presets bar is hidden.

Bug Fixes:

• Reduced brief visual flashing when restoring the workspace’s saved sidebar/toolbar state.

Original source

This adds an experimental way to start and control a coding-agent session running on a desktop host from the iOS app.

The mobile app is a remote UI; the agent process, workspace access, permissions, and native session files stay on the desktop.

The feature is off by default behind Desktop > Settings > Security > Enable live agent sessions (experimental).

• iOS session UI
• relay (authenticated HTTP + WebSocket proxy)
• host-service tRPC + session stream
• AcpSessionManager
• one claude-agent-acp child per active session
• Claude's native on-disk session store

The detailed ACP-vs-direct-SDK walkthrough is in the standalone comparison page. This PR body is the shorter implementation guide for reviewers.

What changed

Area Responsibility packages/host-service Owns adapter processes, ACP JSON-RPC, session state, permissions, the bounded update journal, WebSocket fan-out, tRPC commands, and restart resurrection. packages/host-client (new) Platform-neutral relay transport: SuperJSON tRPC calls, one forced-token refresh after a 401, and fresh authenticated WebSocket URLs on reconnect. packages/session-protocol (new) Shared session/frame contracts, input schemas, timeline fold, reconnect/dedup/reset client, and React hooks. apps/mobile iOS session list and thread UI: open a workspace's context menu > Live sessions, then drive messages, plans, nested tool calls, model/mode/effort controls, permission and question cards, cancel, pagination, and reconnect/error banners. apps/desktop Stores the opt-in security setting and restarts host children with SUPERSET_ACP_SESSIONS=1. It does not render this session UI.

The existing Mastra chat path is not rewritten by this PR; live ACP sessions have a separate mobile route while the feature is evaluated.

Protocol flow

Create and run a turn

The public Superset session id is different from the adapter's native session id.

mobile > host tRPC acpSessions.create { sessionId, workspaceId }
host > adapter initialize
host > adapter session/new { cwd, mcpServers: [] }
adapter> host { sessionId: , modes, configOptions }
host > mobile { sessionId: , status: "idle", ... }

A prompt is admission-acknowledged over HTTP; a potentially long-running turn does not keep a relay request open:

mobile > host tRPC acpSessions.prompt { sessionId, prompt }
host > mobile { accepted: true }
host > adapter session/prompt
adapter> host session/update notifications
host > mobile WS { seq, sessionId, frame }

When the adapter blocks on a tool or AskUserQuestion, the host parks the ACP request and streams a renderable card to mobile. The mobile response resolves that exact request id:

adapter> host session/request_permission { toolCall, options }
host > mobile WS permission_requested { requestId, ... }
mobile > host tRPC respondToPermission { requestId, outcome }
host > adapter { outcome }
host > mobile WS permission_resolved

Single-select, multi-select, and skipped question answers are supported. The adapter's paired free-text *_custom fields are intentionally ignored today, so the mobile flow is tap-only. Multi-select answers use ACP's _meta extension while preserving a normal first optionId for single-select consumers.

Reconnect and restart

Each runtime has a gapless seq journal. A reconnect presents its last sequence; the host replays (since, latest] and then attaches the live subscriber without a handoff gap. Duplicates are ignored. A missing/evicted cursor produces a terminal reset, after which the client refetches state/history and opens a fresh stream URL/token.

Current caveat: the numeric cursor does not yet include a journal-incarnation id. A new journal starts at 1 after host resurrection, so an overlapping pre-restart cursor is not guaranteed to be recognized as stale by number alone. The mobile hook's normal restart path refetches state/history before attaching; making cross-incarnation rejection intrinsic to every cursor is tracked as P0 follow-up.

Host SQLite stores only the durable binding needed to find the harness-owned session again:

Superset session id > workspace id + native ACP session id + harness + cwd

After a host restart, list/get return the row as status: "offline" without starting a process. The first live operation (getMessages, prompt, permission/config command, or stream attach) spawns a new adapter and calls:

host > adapter session/load { sessionId: , cwd }
adapter> host replayed session/update notifications
host > mobile rebuilt transcript + live updates

An in-flight turn and pending permission callbacks do not survive a host restart. Replayed tool calls that were left open are terminalized instead of appearing to run forever.

If the native Claude session file was deleted or is corrupt, session/load fails. The registry row remains offline and retryable; the stream emits reset: "session_load_failed", the hook retries through tRPC, and the actual load error is shown in the thread's destructive error banner. The composer stays hidden until resurrection succeeds, and no replacement session is silently created.

Security and feature gating

• The setting defaults off. When off, the WebSocket route is not mounted and every ACP procedure except list rejects with PRECONDITION_FAILED.
• list remains authenticated but returns { items: [], enabled: false }, so the sessions screen can feature-detect without an extra capability endpoint.
• Existing host auth protects both tRPC and WebSocket paths; reconnects mint a fresh short-lived JWT.
• ANTHROPIC_API_KEY and ANTHROPIC_AUTH_TOKEN are removed at the adapter spawn boundary, so a repo .env cannot override the user's Claude login.
• Host SQLite stores registry metadata only. Message text, tool payloads, permission payloads, and journal frames are not copied into that table.

History, memory, and validation boundaries

The host journal is a fixed-capacity O(1) circular buffer (5,000 envelopes), and pre-runtime session/load replay buffering is capped to the same window. This prevents lifetime-unbounded host memory, but the journal still serves both recent reconnect catch-up and getMessages pagination. Because ACP exposes whole-transcript replay rather than paginated native history, history older than the retained window is not currently available through Superset.

The React hook retains the pages the user loaded plus live envelopes for the current mount so it can refold the timeline. Separating disk-backed history from a much smaller catch-up ring, and bounding the live client overlay, is explicitly follow-up work rather than something this PR claims to have solved.

TypeScript is strict across the production path, but runtime validation is not complete. tRPC inputs are Zod-validated and the official ACP SDK validates its registered request/notification boundary; nested WebSocket payloads, generic relay outputs, adapter responses, and SQLite rows are not all fully parsed by canonical Zod schemas yet. The current truth and the hardening plan are documented in packages/host-service/docs/acp-sessions.md and plans/acp-session-follow-ups.md.

Test coverage

Primary confidence: authenticated real-Claude runs

The ACP_E2E=1 suites are the important compatibility evidence. Nothing at the model/adapter boundary is mocked: they use this Mac's authenticated Claude CLI account, a real Sonnet model, the pinned claude-agent-acp executable, real ACP JSON-RPC over stdio, AcpSessionManager, and the real WebSocket route/client.

The manager suite covers real initialize/create/prompt/fold behavior, a saved multi-agent Workflow, AskUserQuestion, tool permissions, cancellation after permission, first-response-wins, parallel tool use, and adapter death. The stream suite runs the same real adapter/model through the actual WebSocket route and sync client, covering concurrent subscribers, a mid-turn disconnect/cursor reconnect with no gaps or duplicates, and eviction reset/re-attach.

The Workflow assertion does not stop at Claude's asynchronous async_launched acknowledgement. It waits for the persisted run to reach completed, then verifies all five Sonnet agents, non-zero real token/tool usage, two parallel audits, and the final structured verdict. In the latest complete authenticated run, that Workflow finished in 36.1 seconds with 5 Sonnet agents, 77,981 tokens, and 14 tool calls.

Run the full authenticated lane on a logged-in Mac whenever changing the ACP runtime, adapter/SDK, Workflow handling, permissions, questions, cancellation, stream/reconnect/sequencing, or resurrection:

cd packages/host-service
ACP_E2E=1 ACP_E2E_MODEL=sonnet ACP_E2E_EFFORT=low \ bun test \ test/integration/acp-sessions.integration.test.ts \ test/integration/acp-sessions-stream.integration.test.ts

These tests are skipped in ordinary CI only because CI does not have a Claude login and the runs spend real tokens. That is an infrastructure limitation, not a signal that this lane is optional; until an authenticated runner exists, the agent making a relevant change is expected to run it locally and report the real result.

Latest full authenticated result: 10/10 passed, 113 assertions, 72.1 seconds.

One current adapter behavior is pinned explicitly: Claude emits two parallel Bash tool uses together, but claude-agent-acp 0.56.0 exposes their permission callbacks to Superset one at a time. Superset still supports truly simultaneous pending permission requests; that state-machine case is exercised by the deterministic backup below.

Belt and suspenders: deterministic regression breadth

The always-run deterministic ACP adapter is deliberately secondary. It speaks real ACP JSON-RPC over stdio through the official SDK and gives cheap breadth plus exact fault injection, but it uses no Claude model/account/network and cannot establish real adapter/model compatibility.

Covered scenarios include:

• a 30-turn marathon with gapless streaming, pagination, and identical refolding;
• prompt admission/rejection/recovery and concurrent turns;
• allow/deny, stale duplicate answers, multiple pending permissions, and single-/multi-question elicitation forms;
• cancel mid-tool, cancel while permission-blocked, adapter death, and sibling-session isolation;
• stream drop/reconnect from cursor, duplicate suppression, malformed frames, journal eviction/reset, and two concurrent subscribers;
• real host-client question answering, in-flight cancellation, simultaneous permissions, cursor reconnect, host/app/server/SQLite close and rebuild, passive offline listing, session/load transcript replay, bounded replay, and deleted native-session failure;
• mobile presentation regression coverage for the exact missing-transcript banner, the "Session could not be resumed" empty state, and the disabled composer;
• create idempotency/workspace conflicts, list/message cursor validation, model/mode/config updates, title clearing, feature gate/auth, and credential scrubbing;
• relay serialization, real tRPC error messages, 401 refresh-once, and fresh WebSocket tokens.

The host-client boundary suite is another belt-and-suspenders layer: it starts the real createApp host and crosses actual auth, HTTP/SuperJSON/tRPC, WebSockets, child-process stdio, and on-disk SQLite through @superset/host-client; only the model/adapter behavior is deterministic. It is especially valuable for the question, abort, simultaneous-permission, reconnect, full host/app/server/DB rebuild, resume, and missing-native-transcript paths, but it does not replace the authenticated real-Claude lane.

Current ACP evidence on this head: the authenticated Sonnet lane is 10/10 (113 assertions), and the focused deterministic ACP/runtime/host-client lane is 49/49 (553 assertions). Host-service typecheck and root lint also pass. The broader branch baseline previously passed Sherif, 34/34 Turbo typecheck tasks, 14/14 Turbo test tasks (including 835 host-service tests), release typecheck, 15/15 release tests, unified-version validation, and an iOS production Metro export (5,556 modules).

Suggested review order

1. packages/host-service/docs/acp-sessions.md > current behavior and known limits.
2. packages/host-service/src/runtime/acp-sessions/acp-sessions.ts > lifecycle and ACP bridge.
3. packages/host-service/src/runtime/acp-sessions/{persistence,journal,stream}.ts > durability and delivery.
4. packages/session-protocol/src/{api,envelope,state}.ts and src/client/subscribeToSession > shared wire contract.
5. packages/session-protocol/src/react/useAcpSession > resync/pagination state owner.
6. apps/mobile/.../chat/acp/ > iOS presentation and interaction layer.
7. packages/host-service/test/integration/acp-sessions*.test.ts > executable behavior matrix.

Remaining architecture and production-hardening work is centralized in plans/acp-session-follow-ups.md; completed implementation history is archived under plans/done/.

Original source

Adds GPT-5.6 Sol, Terra, and Luna to the Codex new-session model picker.

Tested each ID with codex exec --model <id> "what model are you?" (exit 0), plus unit tests, lint, and typecheck.

Summary by cubic

Added GPT-5.6 Sol, Terra, and Luna to the Codex new-session model picker so users can choose the latest variants. Added tests to verify each model ID is accepted.

Summary by CodeRabbit

• New Features
  • Added support for selecting GPT-5.6 Codex models: Sol, Terra, and Luna.

Greptile Summary

This PR adds three new GPT-5.6 model variants — Sol, Terra, and Luna — to the Codex new-session model picker by inserting entries at the top of the codex preset's model list in AGENT_MODEL_SUPPORT, and adds a covering test for all three IDs.

Three { id, label } entries for gpt-5.6-sol, gpt-5.6-terra, and gpt-5.6-luna are prepended to the codex section of AGENT_MODEL_SUPPORT; ordering is consistent with newest-first across the file.

A new it() block iterates all three IDs and confirms buildAgentModelArgs("codex", model) returns ["--model", model], matching the pattern of adjacent tests.

The new models do not appear in SUPERSET_CHAT_MODELS, unlike gpt-5.5, gpt-5.4, and gpt-5.3-codex which each have openai/-prefixed entries there; whether this is intentional or an oversight is worth confirming.

Confidence Score: 4/5

The change is a small, additive list edit with no functional risk to existing model selections; the only open question is whether the new models should also appear in the Superset chat model list.

The change touches only a static data array and its test. Existing model selections are unaffected, the new entries are validated by the test, and buildAgentModelArgs safely ignores any ID not in the curated list. The one open question — whether gpt-5.6-* should also land in SUPERSET_CHAT_MODELS — could leave those models absent from the chat picker if they are in fact supported there, but does not introduce wrong behavior on the Codex path.

File affected: packages/shared/src/agent-models.ts — specifically whether the new models warrant corresponding entries in SUPERSET_CHAT_MODELS.

Additional notes

The new gpt-5.6-sol/terra/luna models are added only to the Codex section and not to SUPERSET_CHAT_MODELS. If these models are accessible through the Superset chat API (with an openai/ prefix), the omission would mean they never appear in that picker. It is unclear if this omission is intentional or an oversight.

Original source

Relay access no longer requires a paid subscription. The relay gate (checkHostAccess) now grants access based solely on result.allowed from host.checkAccess, dropping the && result.paidPlan requirement. Free-plan users whose host is authorized in their org can now use the relay HTTP proxy and /tunnel WebSocket instead of getting 403 Forbidden / a closed socket.

Scope is limited to the relay server enforcement — the only place that actually blocked free users. The desktop paywall UI is intentionally left untouched. The paidPlan field returned by host.checkAccess is now unused by any consumer but kept in place to minimize the diff.

Test Plan

• Free-plan user's authorized host connects via relay (no 403 / tunnel close)
• Non-authorized host (wrong org) still denied
• Paid-plan behavior unchanged

Summary by cubic

Allow free-plan users with an authorized host to use the relay HTTP proxy and /tunnel WebSocket. Access now relies only on host.checkAccess returning allowed, removing the paid plan check.

Summary by CodeRabbit

Bug Fixes

• Host access is now granted whenever access is approved, including for eligible plans that were previously blocked by an unnecessary plan-status check.

Greptile Summary

This PR removes the paidPlan requirement from the relay access gate, so free-plan users whose host is authorized in their org can now connect via the relay HTTP proxy and WebSocket tunnel. The change is limited to a single expression in checkHostAccess. The ok condition in apps/relay/src/access.ts changes from result.allowed && result.paidPlan to result.allowed, granting relay access based solely on host authorization rather than subscription tier. The paidPlan field returned by host.checkAccess is retained but no longer consumed by any caller; the desktop paywall UI is intentionally unchanged.

Confidence Score: 5/5

Safe to merge — the change is a one-line relaxation of a business-logic gate with no effect on the surrounding auth, caching, or error-handling paths. The only modified line drops && result.paidPlan from the access decision. Host authorization (result.allowed) is still enforced, org membership is still checked locally before any API call, and the LRU caches continue to behave correctly. The unused paidPlan field is kept in the response type to minimise diff surface. No auth bypass, no data-plane change, no cache semantic shift. No files require special attention.

Original source

Summary

• add an owner-only delete action to host settings with typed confirmation and local-host protection
• verify active organization membership and host ownership inside the delete transaction
• issue only the host-row delete; do not query, delete, or update workspaces or automations
• keep the existing workspace foreign key and database schema unchanged
• optimistically remove the host, restore it on failure, and expose the action through settings search

User impact

Owners can remove hosts directly from Settings. Workspace, file, conversation, and automation data is never mutated by this flow. Existing database constraints remain authoritative.

Validation

• focused host deletion tests — 6 passed
• bun run typecheck in packages/db, packages/trpc, and apps/desktop
• bunx drizzle-kit check
• bun run lint
• git diff --check

Greptile Summary

This PR adds an owner-only "Delete host" action to the desktop Host Settings page, backed by a new transactional v2Host.delete tRPC mutation that verifies org membership and host ownership with row-level locks, removes synced workspace rows, pauses related automations, and cascades through host memberships. The optimistic UI removes the host from the Electric collection immediately, navigates the user back to the host list, and shows a success toast once the server confirms.

Backend (v2-host.ts): Membership is pre-checked outside the transaction for an early exit, then host existence and owner role are re-verified inside with FOR UPDATE locks — a solid TOCTOU-safe pattern. Workspaces are deleted before the host to respect the restrictive FK, and automations are paused with a conditional OR/inArray guard that handles the zero-workspace case correctly.

Frontend (DeleteHostSection.tsx): Confirmation dialog with local-host guard; optimistic delete fires before navigation so the host disappears from the list without a loading pause.

Tests (v2-host.test.ts): Auth/authz edge cases are well covered, but the code path where a host has no associated workspaces is not exercised.

Confidence Score: 4/5

Safe to merge — the mutation is well-guarded with transactional row locks and multi-layer ownership checks, and the optimistic UI degrades cleanly on failure.

The security model is solid: org membership is pre-checked outside the transaction and host ownership is re-verified inside with FOR UPDATE locks, preventing TOCTOU races. The main gap is test coverage for the zero-workspace deletion code path, where a different WHERE clause is generated but never exercised by the test suite.

packages/trpc/src/router/v2-host/v2-host.test.ts — the zero-workspace happy-path scenario is missing and should be added to cover the eq(automations.targetHostId) only branch.

Original source

Adds a generic, user-defined wake command to each host, and two CLI commands to manage and run it:

superset hosts set-wake <host> "<command>"   # store the command that turns this host on
superset hosts set-wake <host> --clear        # remove it
superset hosts wake <host>                     # run the stored command locally (with confirm)

The wake command is whatever the user wants — resume a cloud sandbox, fly machine start, an ssh … systemctl start, a script, etc. Superset stays provider-agnostic.

Why

Remote hosts (e.g. a host-service running in an ephemeral cloud VM/sandbox) go offline when their machine stops, and nothing can wake them from the relay side — the machine has to be started by something with the right credentials. Rather than bake in a specific provider, this lets each user attach an arbitrary "how to turn this host on" command and trigger it on demand.

How it works

• v2_hosts.wake_command — new nullable column (migration 0059_add_host_wake_command).
• host.setWakeCommand tRPC mutation (org-membership + host-access checked, like host.setOnline); host.list now returns wakeCommand.
• CLI resolves the host by name or id, then:
  • set-wake stores/clears the command.
  • wake shows the command, asks for confirmation (--yes to skip), and runs it locally in a shell, streaming output. It runs on the caller's machine — that's where the credentials/CLIs to start a remote box live; the browser/server can't exec arbitrary local commands.

Scope / follow-ups

• CLI + data model only. The mutation and list field are the shared backend, so a UI can read/set the command too.
• UI: a set-the-command text field fits the web host settings page. A run/wake button belongs in the desktop app (Electron has a shell); the pure web app can't execute the command locally. Wiring those is the natural next PR.
• Confirmation-before-run guards against an org member setting a hostile wake command that another member's machine would execute.

Migration

⚠️ packages/db/drizzle/0059_add_host_wake_command.sql (ALTER TABLE "v2_hosts" ADD COLUMN "wake_command" text;) is generated but not applied — needs to run on a Neon branch / prod per the usual flow.

Testing

• typecheck + lint pass; CLI builds and both commands are discovered (superset hosts --help).
• ⚠️ The end-to-end wake run (local shell exec + confirm) hasn't been exercised against a live host yet.

Summary by cubic

Add a per-host, user-defined wake command with CLI commands to set and run it, so users can start hosts from their local machine across any provider. Only the host owner can set the command. Stored on v2_hosts.wake_command (migration 0059) and exposed via tRPC and the CLI.

New Features

• CLI: superset hosts set-wake "" to set; --clear to remove (conflict-guarded).
• CLI: superset hosts wake runs the stored command locally; --yes skips confirm; fails on non-zero exit or signal kill; does not spawn if already aborted.
• Host resolution by name or id in the CLI.
• tRPC: new host.setWakeCommand mutation (owner-only); host.list and automation dispatch now include wakeCommand.
• DB: new nullable v2_hosts.wake_command column.

Dependencies

• Bump bun-types to 1.3.14 in workspace-client and lockfile.

Summary by CodeRabbit

New Features

• Added CLI support to configure or clear a host “wake command”, and to execute it with optional confirmation.
• Host details and listings now expose the configured wake command when available.
• CLI host targeting now accepts either a host name or a host ID.

Bug Fixes

• Improved validation and messaging for missing hosts, ambiguous matches, and attempts to run when no wake command is set.
• Enhanced wake execution handling (cancellation, confirmation cancelation, and clearer failures on non-successful runs).

Additional notes from reviews:

• Signal-killed process resolves as exit-code 0 (false success) issue fixed: runLocally now rejects with a clear error when the child exits via a signal.
• setWakeCommand is now owner-only to prevent any host member from overwriting the shared wake command.
• Conflict between --clear and a command argument now errors instead of silently dropping the command.

This update introduces a flexible and secure way to manage wake commands for hosts, improving user control and safety when starting remote hosts across various providers.

Original source

When a terminal pane can't connect, it just shows "disconnected" with no cause — which is exactly what made the recent cross-region relay bug hard to spot (control plane worked, only the terminal WS 502'd). The root difficulty: the browser WebSocket API hides the upgrade's HTTP status — a relay 502/503 only surfaces as close code 1006, so the client can't see why.

Both changes lean on the _whoowns preflight the client already fires before every terminal WS (its response status was thrown away until now).

1. Classify the failure (surface the why).

On give-up, the pane log now says the cause instead of a generic close:

• preflight 503 → "This host is offline (not connected to the relay)."
• preflight 401/403 → "You don't have access to this host."
• preflight 200 but the WS still drops → "The host is online (region X) but the terminal stream couldn't connect — usually a relay routing issue." ← the fingerprint of the cross-region bug
• preflight unreachable → "Couldn't reach the relay service."

2. Emit terminal_connect_failed telemetry on give-up (PostHog), so this failure mode is queryable/alertable instead of silent:

{ endpoint, close_code, close_reason, preflight_status, tunnel_region, reconnect_attempts, category } (endpoint has the token stripped).

Notes:

• primeRelayAffinity now returns { status, region } | null (was void); both existing callers ignore the value, so it's backward-compatible.
• Fires once per give-up (max reconnect attempts reached), not on every transient blip.
• Pure classifier + probe-parsing are unit-tested and mutation-checked. Desktop typecheck + biome clean.

Follow-on ideas from the same discussion (not in this PR): a bounded error state with Retry/Copy-diagnostics buttons, and a cross-region synthetic check in the relay (today's synthetic.ts only exercises same-region).

Summary by cubic:

Surface why a terminal can’t connect and emit telemetry on final failure. We classify errors using the relay _whoowns preflight (now probed with the wsUrl), show a clear message in the pane, and send a PostHog event for alerting.

New Features:

• Show a specific reason on give-up: 503 host offline, 401/403 no access, 200-but-WS-drops = relay routing issue (with region), 502/504 = temporary relay failure, or relay unreachable.
• Emit terminal_connect_failed on give-up with endpoint, close_code, close_reason, preflight_status, tunnel_region, reconnect_attempts, category.
• Only applies to relay-host terminals (/hosts/...); local terminals unchanged.

Refactors:

• @superset/workspace-client primeRelayAffinity now returns { status, region } | null (and exports RelayAffinityProbe) and is used to classify failures; added unit tests for probe parsing and classification.
• Probe _whoowns with the original wsUrl (not actualUrl); deduplicated diagnostics comments and centralized rationale in primeRelayAffinity.

Summary by CodeRabbit:

New Features:

• Terminal connections now run a relay-aware precheck for relay-routed hosts and generate more specific user-facing failure diagnoses.

Bug Fixes:

• Improved “max reconnect attempts reached” reporting with expanded diagnostic context (failure category, preflight status, tunnel region when available) and more detailed failure analytics.

Tests:

• Added/expanded automated coverage for relay affinity probing and terminal failure classification to ensure consistent categorization across common HTTP and stream-drop scenarios.

Greptile Summary:

This PR surfaces actionable failure reasons when a relay-routed terminal can't connect, and emits terminal_connect_failed PostHog telemetry on give-up. It leverages the existing _whoowns preflight — whose HTTP response status was previously discarded — to classify the WebSocket close into four categories (host-offline, unauthorized, stream-blocked, relay-unreachable) that the browser's WebSocket API cannot distinguish on its own.
primeRelayAffinity now returns RelayAffinityProbe | null (status + region) instead of void; both existing callers are backward-compatible since they ignore the return value.
_lastProbe is stored on the transport and refreshed on every reconnect attempt, so the give-up message and telemetry reflect the most recent probe — correctly fingerprinting the cross-region routing bug (200 preflight + 1006 WS close → stream-blocked).
The new classifyTerminalFailure pure function and both test suites have good branch coverage; the token is stripped from the endpoint telemetry field via formatWsEndpoint.
Confidence Score: 4/5 Safe to merge. The probe already fired on every connect; storing and reading its result only in the give-up branch is a pure additive change with no impact on the reconnect lifecycle.
The behavioral change is additive — the probe already fired on every connect and the result was thrown away; now it is stored and read only in the give-up branch. Both flagged items are minor quality improvements: 502 falling to the unknown catchall produces a slightly less helpful user message, and the relay parameter leak is harmless in practice. No auth, data-integrity, or crash risk is introduced.
terminalConnectionDiagnostics.ts — the 502 gap and the probe-URL parameter suggestion are both there; otherwise all files are straightforward.

Original source

Problem

Terminal panes on a remote host show a permanent "disconnected" whenever the host runs in a different Fly region than the client — e.g. a Vercel Sandbox host (us-east / iad) with a desktop in the west (sjc). The relay fleet is one machine per region (sjc, iad, fra, nrt, sin, gru), so cross-region is the normal case.

Diagnosis (reproduced against a live Vercel-sandbox host)

• _whoowns → {ok:true, region:"iad"}, terminal.createSession (HTTP) → 200, a terminal is really created on the host.
• The terminal/events WebSocket upgrade → 502 from Fly (fly-request-id …-sjc).

Root cause: the relay routes cross-node traffic with Fly-Replay, which is transparent for HTTP but cannot route a WebSocket upgrade — the replay header rides on a response that only arrives after the handshake, so the client sees a non-101 and fails (1006/502). The _whoowns affinity preflight sets no real Fly stickiness cookie, so the WS lands on the wrong region and 502s. The CLI works because it talks to the daemon over the local socket, bypassing the relay.

Fix

When a WS upgrade lands on a relay node that doesn't own the host's tunnel, bridge it to the owning node over Fly's private 6PN network (.vm..internal) instead of fly-replaying:

• auth middleware: WS upgrades never fly-replay; if another instance owns the tunnel it hands the WS handler the owner (JWT is verified here; the owning node still runs checkHostAccess).
• WS handler: opens a ws://….internal connection to the owner and pipes frames both ways, preserving text (client→host JSON) vs binary (host→client PTY bytes) framing.
• _rlp=1 loop guard: a proxy hop that lands on a non-owner (stale directory) fails instead of re-proxying.
• Bind the server dual-stack (::) so peers are reachable over IPv6 6PN; add FLY_APP_NAME for the internal address.

Same-instance connections (the common same-region case) are unchanged — the proxy only engages when hasTunnel is false.

Verification

• Typecheck + biome clean.
• Not yet runtime-verified — needs a deploy to the multi-region fleet. Best test bed: the Vercel-sandbox host in iad + desktop in sjc that currently reproduces the 502. Plan to confirm the terminal WS returns 101 and the pane connects post-deploy.

Risk / rollout notes

• The :: bind is the one change to watch: Fly health checks + public traffic must stay green (dual-stack accepts IPv4-mapped on Linux, V6ONLY=0). Recommend deploying one machine and watching /health before fleet rollout.
• No client/desktop change required; the _whoowns preflight becomes redundant but harmless.

Summary by cubic

Fix cross-region terminal disconnects by proxying terminal/events WebSockets to the owning relay instance over Fly’s 6PN network. This restores proper 101 upgrades and stable terminals when host and client run in different regions.

• Bug Fixes
  • Route WS upgrades to the owning relay over 6PN using ws://.vm..internal instead of replaying.
  • Bridge frames both ways, preserving text/binary framing and using safe close codes.
  • Add _rlp=1 hop guard to prevent loops when ownership is stale.
  • Bind server to :: for IPv6/6PN and add FLY_APP_NAME to build internal addresses.
• Refactors
  • Extracted WS proxy bridge into proxy.ts with local integration tests in proxy.test.ts covering framing, pending-buffer flush, and close-code propagation.

Summary by CodeRabbit

• New Features
  • Added cross-instance WebSocket bridging for tunnel hosts owned by other relay instances.
  • Introduced a new environment setting to identify the relay app name for internal routing.
• Bug Fixes
  • Improved WebSocket upgrade handling by using directory-based ownership to route requests to the correct relay instance.
  • Prevented failed upgrades by returning a clear “Host not connected” response when no eligible proxy path exists.
• Tests
  • Added coverage for proxy URL construction, safe close-code handling, and bidirectional WebSocket bridging behavior.

Additional notes

• Token not forwarded for Authorization-header clients: internalProxyUrl builds the upstream URL from url.search only. If a non-browser WS client sends the bearer token in an Authorization: Bearer header, that token never makes it into the proxied URL and the owning node sees no credentials → 401 → the client WebSocket opens briefly and then closes with 1011. Browser clients are safe since they always use ?token=, but any desktop/CLI client that upgrades to WS with an Authorization header would silently fail whenever cross-region proxying kicks in.
• No timeout on upstream 6PN connection: If the owning relay's 6PN address is temporarily unreachable, new WebSocket(target) hangs until the OS TCP timeout fires (typically 75–120 s). During that window the client WebSocket is stuck open in proxy mode, unable to send or receive. An explicit AbortSignal / setTimeout on upstream with a ws.close(1013, "Upstream timeout") fallback would bound the hang to something reasonable (e.g. 10 s).
• safeCloseCode function updated to preserve valid protocol close codes such as 1001/1011 and only fall back for reserved/abnormal codes like 1005/1006/1015 to avoid suppressing client reconnect behavior.
• The bridging logic is well-structured: JWT is verified on both relay hops, the loop guard prevents directory-stale re-proxying, and pending frames are bounded. Main gaps include implicit reliance on query-param token delivery, no explicit timeout on the 6PN upstream connection, and the _rlp=1 guard being client-observable. None affect the primary browser terminal use-case but are worth tracking before reuse for other WS channels.
• Important files changed include apps/relay/src/index.ts and apps/relay/src/proxy.ts.
• Confidence Score: 4/5
• Safe to merge with the caveat that it has not been runtime-verified against the live fleet; the dual-stack bind is the one operational change worth watching on first deploy.

Original source

Fixes the client-side request storms behind the 2026-07-08 auth outage, where a broken-session desktop client hammered api.superset.sh hard enough to trip Vercel's automatic per-IP DDoS mitigation (403 x-vercel-mitigated: deny) — which then denied every path on the host, including the login endpoint, locking the user out of re-authenticating (self-lockout).

There were two storm sources in the same broken-session failure mode:

1. POST /api/auth/token — Electric JWT refresh (the dominant one, per #5513)

Every Electric shape/collection shared one onError handler that called authClient.token() on each 401 with no dedup, backoff, or circuit breaker. When a session breaks, every shape 401s at once and the refreshed token is still rejected, so each shape loops — across a heavy multi-workspace client that's hundreds of token requests (~300× baseline in the reporter's NetLog: 1,834 events ≈ 600 requests vs ~2).

Fix — route the 401 refresh through a shared gate (renderer/lib/jwt-refresh):

• single-flight: concurrent shape 401s collapse to one /api/auth/token call
• exponential backoff keyed on consecutive failures (3s floor → 60s cap)
• circuit breaker after 5 failures (5-min cooldown) — a permanently-broken session stops hitting the API instead of storming it

2. GET /api/auth/get-session — sign-in recovery poller

useSessionRecovery polled on a flat 15s interval with no backoff/cap/terminal state; a stuck token polls forever, and a synchronized fleet adds to the storm.

Fix — exponential backoff (15s → 5min cap) + ±50% jitter (desyncs the fleet) + a 12-attempt budget, then idle until a user-driven focus/visibility event re-arms it.

Testing:

• Unit (bun test): 14 tests across both pure cores — nextRecoveryDelayMs and shouldAttemptJwtRefresh / applyJwtRefreshResult (backoff, cap, stop, jitter, single-flight, circuit).
• Mutation-verified: removing each protection (cap / stop / exponential / jitter / single-flight / circuit / success-reset) makes the specific guarding test fail — confirmed then reverted.
• CDP runtime: imported the real shipped useSessionRecovery module in the running dev renderer and drove the full cadence (first 9059ms in-band, caps at 300000ms, jitter 52849≠45135, stops at budget).
• bun run lint + desktop typecheck clean.

Scope / not included (deliberately):

• Server-side firewall isolation (issue's fix — put the auth entrypoint on its own origin so a per-IP deny can't block re-auth) is not here — it's infra work and the acute incident has recovered. Worth a follow-up as defense-in-depth for un-updated clients, but out of scope for this client fix.
• Hard-403 client UX (issue's fix — surface "temporarily blocked, retry in N min" instead of opening a plain 403) — small follow-up, not included.
• AuthProvider.tsx's 50-min refreshJwt is intentionally left unchanged (signed-in-only cadence, not a storm contributor).

Summary by CodeRabbit:

• New Features:
  • Improved sign-in session recovery using bounded exponential backoff with symmetric jitter, with retry resets on focus/visibility changes.
  • Added a centralized JWT refresh gate to deduplicate concurrent refreshes and throttle retries with an error circuit.
• Bug Fixes:
  • Replaced fixed polling with a cancellable, attempt-limited scheduler and ensured recovery stops after the configured maximum attempts.
• Tests:
  • Added deterministic coverage for jitter/backoff timing and for JWT refresh retry and circuit behavior.

Original source

Type of Change

• Bug fix

Root cause

Two independent issues, both ending in "the diff doesn't use the theme's colors":

1. The theme never reached the diff renderer.

The v2 diff view renders through @pierre/diffs, which does its syntax highlighting on a shared background worker pool. That pool keeps its own theme and only picks it up at creation or when explicitly updated — it ignores the per-diff theme option the app was passing. We never set a theme on the pool, so it stayed on the library's defaults (pierre-dark/pierre-light) and the app's theme was dropped. This may have regressed in #4898, which moved diffs onto the pool; the previous diff path had no pool, so it may have themed correctly.

1. Custom theme colors weren't persisted.

Theme state is saved through the uiState.theme.set tRPC endpoint, whose Zod schema listed every Theme field except editor (the editor/diff color + syntax overrides). Zod strips unknown keys, so each save silently dropped editor. Imported themes looked correct during the session but reloaded without their syntax colors after a restart, falling back to a generated palette — in both the editor and the diff.

(Distinct from #3013 / #3567 / #2684 / #3569, which are about the +/- line-change colors, not syntax highlighting or persistence.)

Fix

• Sync the theme to the pool — a small DiffThemeSync component, mounted next to the diff worker-pool provider, updates the pool's theme whenever the app theme changes. The library resolves the theme on the main thread, ships it to the workers, and re-renders open diffs.
• Persist editor — added the missing editor field to the theme persistence schema so custom themes keep their colors across restarts.

Themes saved before this change must be re-imported once to restore their editor colors.

Testing

• bun test — added a unit test for the pool theme options
• bun run typecheck and bun run lint — clean
• Manual: imported a custom theme with distinct syntax colors → diff tokens render in the theme's colors instead of the library default; switching themes updates open diffs live; colors now survive an app restart

How to reproduce

1. Download monokai-pro-superset-theme.json — a custom theme with a full editor.syntax block.
2. Settings → Appearance → Import theme → select it → activate.
3. Open any diff → syntax tokens render in the theme's colors (pink keywords #FF6188, yellow strings #FFD866, green functions #A9DC76), not the library default.
4. Reload (Cmd-R) → colors persist.

Summary by cubic

Fixes diff syntax theming by applying the active app theme to the @pierre/diffs worker pool and persisting Theme.editor. Diff views now use the right colors for custom and built-in themes, survive reloads, and pool/per-item diff options stay in sync; if you saved a custom theme before this change, re-import it once to restore editor syntax colors.

Bug Fixes

• Sync the active theme to the @pierre/diffs worker pool via DiffThemeSync, calling setRenderOptions on theme changes and sharing diff/tokenize options through DIFF_POOL_RENDER_OPTIONS so CodeView items and the pool use the same settings.
• Persist Theme.editor by adding an editor field to the Zod themeSchema (colors and syntax as records), fixing custom theme syntax being dropped on save and lost after restart.
• Guard the pool call with optional chaining and log setRenderOptions rejections with console.error to avoid unhandled promise rejections.

Refactors

• Constrain DIFF_POOL_RENDER_OPTIONS with satisfies Partial<RenderDiffOptions> to catch invalid or renamed render-option keys at build time.

Summary by CodeRabbit

New Features

• Diff views now synchronize with the active app theme for more consistent styling.

Bug Fixes

• Custom theme editor color/syntax overrides now persist correctly after reopening.
• Improved diff rendering consistency by applying shared worker-pool diff render options so tokenization stays aligned.

Tests

• Added unit tests to verify diff theme naming and core diff render-option settings.

Original source

Bring Your Own Terminal Agents

You can now add your own custom terminal agents alongside the built-ins, each with its own icon and launch command.

• Register any CLI agent and give it a name and icon
• Runs everywhere the built-in agents do
• Polygraph ships as a new built-in terminal agent

Redesigned Workspace Activity Strip

The v2 sidebar now surfaces what each workspace is actually doing in a single compact activity strip.

• Running agents and forwarded ports live inline on the workspace item
• Running and PR state persist across restarts, with a Clear Status action
• Live-work sections are emphasized so in-progress workspaces stand out
• Agent chips stay hidden unless multiple agents are running

Fable 5 and Reasoning Effort

Launch agents with the Fable model family and pick a reasoning-effort level right from the workspace.

• Fable 5 available in the copilot, cursor-agent, and opencode model pickers
• Model picker added to the workspace create dialog

Workspace Dock Badge

The macOS dock icon now shows a badge for workspaces with unread activity or that need your attention, so you can step away and still know when an agent wants you.

Improvements

Real tables for Automations & Workspaces — sortable columns, grouped project headers, row context menus, and an overflow fix.

• Loud automation failures - Automation runs now surface failures instead of failing silently
• View files outside the workspace root - Open and inspect files beyond the workspace directory
• "Last used" sign-in badge - See which method you last signed in with
• Restored-session separator - A clear marker shows where a v2 terminal cold-restored a previous session
• Quit Superset Completely - New macOS app menu item to fully quit
• Configurable port badges - Choose where v2 port badges open from Settings → Links

Bug fixes

• Fixed file navigator lag and empty-folder-on-expand
• Fixed Cmd+Backspace sending a bare Ctrl-U in the terminal
• Shift+Enter now inserts a newline in terminal chat TUIs
• Restored the native right-click edit menu for text inputs
• Batched folder-level Discard All to avoid git index.lock races
• Fixed terminal resize bricking the parser mid inline-image decode
• Kept workspace PR and diff state from drifting out of sync with GitHub
• Recovered v2 forwarded ports promptly after a host-service restart
• Detect ports for terminals without an attached renderer
• Kept device and workspace host in sync for automations
• Fixed billing to read invoices from the org's canonical Stripe customer
• Stopped force reload from hijacking reopen tab
• Kept traffic-light chrome and sidebar icons a constant size under page zoom

Original source

Summary

• Reframe the Slack agent's SYSTEM_PROMPT opener — it described the bot as a task-management assistant, but it can also spawn workspaces and run coding agents.
• Add that capability to the "You can" list and add one guideline so the bot defaults to action: for code-change requests, prefer spawning a workspace + agent over just filing a task.

Why / Context

For "can someone fix X" style messages the bot tended to file a task or ask questions rather than kick off the work, partly because the prompt only framed it around task tracking. This nudges it toward action while keeping it a general Slack assistant.

Testing

• bunx biome check on the changed file — clean
• No automated tests added (prompt-text-only change)

Notes

• Only the static SYSTEM_PROMPT string changed; the dynamic context interpolation (org, channel, members, statuses, hosts) is untouched.
• The prompt is shared across the v1 and v2 MCP feature-flag paths (FEATURE_FLAGS.SLACK_MCP_V2). Workspace/agent spawning is a v2 capability; on v1 the bot adapts to the tools it's given.

Summary by CodeRabbit

Improvements

• Slack assistant prompt updated to focus on Superset-related tasks and tool usage.
• Guidance restructured to emphasize using Superset tools, workspace spawning, and launching coding agents.
• Assistant more proactive: when intent is clear (especially for code changes), it favors spawning a workspace/agent to take action.
• Retains task creation, formatting, error handling, sourcing, and context-gathering behaviors.

Greptile Summary

This PR rewrites the static SYSTEM_PROMPT in the Slack agent to make the bot proactively spawn workspaces and launch coding agents for code-change requests, rather than filing a task or asking clarifying questions.

• Bias toward action section added: the model is instructed to spawn a workspace + agent whenever intent is reasonably clear, reserving tasks for explicit "track for later" requests.
• Spawning workspaces and agents section added: step-by-step guidance to call superset_projects_list, check superset_workspaces_list for duplicates, derive a kebab-case branch slug, match the user's online host, and spawn via superset_workspaces_create/superset_agents_run.

Confidence Score: 3/5

The change is prompt-only, but the new spawning guidance names v2-specific tools that don't exist on the v1 code path, and the bias-toward-action instruction amplifies the impact of that mismatch on every code-change request routed through v1.

The new sections hard-reference four tool names absent on the v1 MCP path; with the bias-toward-action instruction now in place, the model will actively try to spawn for any code-change request and on v1 will either error out or appear to comply without actually doing anything.

apps/api/src/app/api/integrations/slack/events/utils/run-agent/run-agent.ts — the v1/v2 tool-name mismatch in the new prompt sections warrants a second look before merging.

Spawning workspaces and agents

• Before spawning, call superset_projects_list and pick the project that best matches the request. Match on repository name, project slug, and topic keywords drawn from the user's message and the thread/channel context.
• If the request concerns the Slack app, Superset features, the tasks or automations UI, or anything about Superset itself, use the Superset project (slug: superset).
• If several projects could plausibly match, pick the strongest candidate, state in one short sentence which you picked and why, and proceed — don't stall on the choice.
• Also call superset_workspaces_list and check for an existing active workspace on a relevant branch. superset_workspaces_create always creates a new workspace, so when a relevant one already exists, mention it to the user instead of silently duplicating it.
• Derive the branch name from the request as a short kebab-case slug (e.g. fix-slack-retry, add-csv-export).
• For the host, use the requesting user's own machine when it appears online in the Hosts list in your context (match the host name against the current user); otherwise fall back to the sandbox host.
• Spawn the agent as part of workspace creation when possible — superset_workspaces_create accepts an agents array — or call superset_agents_run against the workspace afterward. Use the claude agent preset unless the user asks for another. Give the agent a clear, self-contained prompt describing the change to make.

Hardcoded superset slug is a silent failure risk

The prompt hard-wires the string superset as the project slug for all Superset-related requests. If that project is ever renamed or its slug changes in the database, the bot will silently pass the wrong slug to superset_workspaces_create and the spawn will fail (or land in the wrong repo). A softer phrasing — e.g. "use the project whose slug or name best matches 'superset'" — would let the model recover by calling superset_projects_list and selecting the closest match at runtime.

Additional notes:

• Host-to-user name matching may always fall through to sandbox because the instruction assumes a host's name field correlates with the current user's display name or email, which may not hold true.
• Consider surfacing ownership metadata to make the heuristic more reliable.

Overall, this update makes the Slack agent more proactive in spawning workspaces and launching coding agents for code-change requests, improving efficiency and responsiveness.

Original source

Superset is now usable from a lot more places than the desktop app: a fleshed-out CLI and TypeScript SDK, a Slack agent that spins up workspaces on its own, and a mobile app heading into internal review.

Automations

Automations are cron jobs for agent sessions. Pick a project, write a prompt, set a schedule — and Superset dispatches an agent run against a fresh workspace every time it fires. The output is a live workspace you can open, review, and continue interactively.

Typical uses:

• Nightly standups — summarize PRs, issues, and activity from the last 24 hours
• Release notes — draft from merged commits each week
• Security & dependency sweeps — scan for vulnerable packages or deprecated APIs every morning
• Long-running refactors — "bump TypeScript to 5.7 in the next un-migrated package" on a daily cadence

This batch brings automations into their own as a first-class workflow:

• Prompt version history — every edit to an automation's prompt is snapshotted. Browse previous versions and restore any of them, so an accidental change is no longer a one-way door.
• Redesigned automations tab — new layout that makes a queue of runs easier to scan at a glance.
• Mine vs. Team filter — automations now belong to a team. Filter the runs view between Mine and Team to see only what you ran vs. everything your team kicked off.

Drive them from the CLI

Everything you can do in the UI is now scriptable. New in this batch: prompt get / prompt set and the --name filter on list.

# create a recurring run from a prompt file
superset automations create \
--name "Nightly audit" \
--rrule "FREQ=DAILY;BYHOUR=3;BYMINUTE=0" \
--project <projectId> \
--agent claude \
--prompt-file prompt.md

# manage the queue
superset automations list --name "Nightly"
superset automations pause <id>
superset automations resume <id>

# iterate on the prompt (backed by the new version history)
superset automations prompt get <id> > prompt.md
$EDITOR prompt.md
superset automations prompt set <id> --file prompt.md

# fire one off-schedule (also works from the SDK / Slack bot / MCP)
superset automations run <id>

superset automations run is also exposed via the TypeScript SDK and MCP, so you can dispatch runs from a CI job, an internal admin panel, or a Slack slash command. See the Automations docs for the full surface.

Superset CLI

The superset CLI grew real project and workspace commands and a cross-device login flow.

New commands:

• superset projects create — scaffold a new Superset project from your shell.
• superset projects setup — link an existing local repo to a Superset project.
• superset workspaces open — open a workspace directly from the terminal.
• superset auth login — now uses OAuth device code + PKCE, so it works on headless servers and across devices.

Setting it up:

# install
curl -fsSL https://superset.sh/cli/install.sh | sh
# or: brew install superset-sh/tap/superset
# or: it's already bundled with the desktop app at ~/.superset/bin/superset

# sign in (opens a browser, or prints a code for a second device)
superset auth login

# scaffold a project and open a workspace
superset projects create
superset workspaces open

The accompanying TypeScript SDK (@superset_sh/sdk) mirrors the CLI 1:1 — same procedures, same shapes — so anything you can do from your shell, you can do from a script, a CI job, or an internal tool.

Linux superset start and superset update are now fixed.

Slack bot

@superset in Slack is now an actual agent, not a task-filer. Mention it in a channel or DM it from anywhere, and it can:

• Create, update, search, and triage tasks from the conversation it's standing in — pulling assignees, statuses, and priorities from your team's Linear/Superset setup.
• Spin up a cloud workspace and launch a coding agent to actually do the work. For code-change requests (e.g. "@superset bump our Sentry SDK to v9 across all apps"), it now defaults to spawning a workspace and agent rather than just filing a ticket.
• Read the thread or channel history on its own to gather context — no need to copy-paste the prior messages.
• Search the web with citations when a request needs up-to-date info.
• Unfurl Superset task and workspace links with rich previews when they're shared in a channel.

Setting it up:

In the dashboard, go to Integrations → Slack.
Click Connect to install the Superset Slack app into your workspace (OAuth).
Mention @superset in any channel, or open a DM with the bot, and describe what you want done.

If Slack was already connected before this release, no action needed — proactive workspace creation is on by default.

Mobile: internal review

The mobile app is in internal review. Core flows — workspaces list, task triage, agent chat, and the live terminal viewer — are wired up against the same APIs as web and desktop. We're dogfooding on-device now ahead of a wider beta.

Also in this batch

• Teams as a first-class primitive — assign members, workspaces, and automations to a team. Powers the Mine/Team automations split above.
• Terminal sessions survive app updates — the PTY daemon hands off file descriptors on upgrade, so running shells stay alive when Superset auto-updates.
• Web terminal presets — run your common commands with a single click in the web terminal, same as desktop.

Minor updates

V2 changes tab gained inline stage/unstage/discard controls and diff comments gained a copy action. Workspaces can be started with a preset for repeatable agent runs. The relay server now drains tunnel connections cleanly on shutdown ahead of the multi-region rollout. Theme search in the command palette. macOS notifications now include workspace and project context. MCP OAuth access token TTL bumped to 7 days.

Original source