@vellumai/assistant 0.4.43 → 0.4.44

package/src/config/bundled-skills/doordash/lib/session.ts

@@ -1,8 +1,9 @@
 /**
  * DoorDash session persistence.
- * Stores/loads auth cookies from a recording or manual login.
+ * Stores/loads auth cookies via the credential store.
  */
 
+import { execFile } from "node:child_process";
 import {
   existsSync,
   mkdirSync,
@@ -11,12 +12,12 @@ import {
   writeFileSync,
 } from "node:fs";
 import { join } from "node:path";
+import { promisify } from "node:util";
 
 import { ConfigError } from "./shared/errors.js";
-import type {
-  ExtractedCredential,
-  SessionRecording,
-} from "./shared/recording-types.js";
+import type { ExtractedCredential } from "./shared/recording-types.js";
+
+const execFileAsync = promisify(execFile);
 
 export interface DoorDashSession {
   cookies: ExtractedCredential[];
@@ -56,22 +57,25 @@ export function clearSession(): void {
 }
 
 /**
- * Import cookies from a Ride Shotgun recording file.
+ * Import cookies that the daemon saved to the credential store under the
+ * target domain key. Copies them into the local DoorDash session file.
  */
-export function importFromRecording(recordingPath: string): DoorDashSession {
-  if (!existsSync(recordingPath)) {
-    throw new ConfigError(`Recording not found: ${recordingPath}`);
-  }
-  const recording = JSON.parse(
-    readFileSync(recordingPath, "utf-8"),
-  ) as SessionRecording;
-  if (!recording.cookies?.length) {
-    throw new ConfigError("Recording contains no cookies");
+export async function importFromCredentialStore(
+  targetDomain: string,
+): Promise<DoorDashSession> {
+  const { stdout } = await execFileAsync("assistant", [
+    "credentials",
+    "reveal",
+    `${targetDomain}:session:cookies`,
+  ]);
+  const cookies = JSON.parse(stdout.trim()) as ExtractedCredential[];
+  if (!cookies.length) {
+    throw new ConfigError("No cookies found in credential store");
   }
+
   const session: DoorDashSession = {
-    cookies: recording.cookies,
+    cookies,
     importedAt: new Date().toISOString(),
-    recordingId: recording.id,
   };
   saveSession(session);
   return session;

package/src/config/bundled-skills/twitter/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: twitter
-description: Read and post on X (formerly Twitter) via OAuth or browser session
+description: Read and post on X (formerly Twitter) via OAuth or managed mode
 compatibility: "Designed for Vellum personal assistants"
 metadata: {"emoji":"𝕏","vellum":{"display-name":"X","user-invocable":true}}
 ---
@@ -9,89 +9,63 @@ You are an X (formerly Twitter) assistant. Use the `bash` tool to run `assistant
 
 ## Connection Options
 
-There are three supported ways to connect to X. Choose whichever fits the user's situation.
+There are two supported ways to connect to X. Choose whichever fits the user's situation.
 
 ### Managed mode (platform-hosted credentials)
 
-When `twitter.integrationMode` is set to `managed`, the platform holds the OAuth credentials and proxies Twitter API calls on behalf of the assistant. No local OAuth setup or browser session is needed.
+When `twitter.integrationMode` is set to `managed`, the platform holds the OAuth credentials and proxies Twitter API calls on behalf of the assistant. No local OAuth setup is needed.
 
-- Supports: **post** and **reply** (routed through the platform proxy)
-- Read-only operations still use the browser path when available.
+- Supports: **post**, **reply**, and **read** operations (routed through the platform proxy)
 - Prerequisites: The assistant must be registered with the platform (`PLATFORM_ASSISTANT_ID`), have an API key (`credential:vellum:assistant_api_key`), and the assistant owner must have connected their Twitter account on the platform.
-- The strategy is automatically set to `managed` when `integrationMode` is `managed` and prerequisites are satisfied.
 
 **Error scenarios in managed mode:**
-- *"Assistant not bootstrapped"* — The assistant API key is missing. Run setup.
-- *"Local assistant not registered with platform"* — `PLATFORM_ASSISTANT_ID` is not set.
-- *"Connect Twitter in Settings as the assistant owner"* — The owner hasn't connected their X account on the platform yet.
-- *"Sign in as the assistant owner"* — The current user is not the assistant owner.
-- *"Reconnect Twitter or retry"* — The platform's OAuth token may have expired. Reconnect on the platform.
+- *"Assistant not bootstrapped"* -- The assistant API key is missing. Run setup.
+- *"Local assistant not registered with platform"* -- `PLATFORM_ASSISTANT_ID` is not set.
+- *"Connect Twitter in Settings as the assistant owner"* -- The owner hasn't connected their X account on the platform yet.
+- *"Sign in as the assistant owner"* -- The current user is not the assistant owner.
+- *"Reconnect Twitter or retry"* -- The platform's OAuth token may have expired. Reconnect on the platform.
 
 **Architecture notes for managed mode:**
 
 - **Assistant hosting mode and Twitter credential mode are separate concepts.** An assistant can be self-hosted (local daemon) yet use managed Twitter credentials, or platform-hosted yet use local BYO OAuth. The `twitter.integrationMode` config controls credential mode; the assistant's hosting mode is determined by its lockfile entry.
 - **Managed Twitter is bound to the assistant owner.** Only the owner of the assistant (as determined by the platform) can connect or disconnect the Twitter account. Non-owner users receive a `403` with an `owner_only` or `owner_credential_required` error code.
-- **Connect/disconnect/status uses desktop session authentication.** The macOS Settings UI calls the platform's Twitter OAuth endpoints using the user's `X-Session-Token` header (obtained during managed sign-in via WorkOS). This authenticates the human user, not the assistant.
-- **Actual Twitter API calls use assistant-level API key authentication.** At runtime, the proxy client sends `Authorization: Api-Key {assistant_api_key}` — it never includes user-level session tokens or OAuth tokens. This ensures the assistant's identity is what the platform uses for token lookup and rate limiting.
+- **Connect/disconnect/status uses desktop authentication.** The macOS Settings UI calls the platform's Twitter OAuth endpoints using the user's WorkOS-issued token. This authenticates the human user, not the assistant.
+- **Actual Twitter API calls use assistant-level API key authentication.** At runtime, the proxy client sends `Authorization: Api-Key {assistant_api_key}` -- it never includes user-level tokens. This ensures the assistant's identity is what the platform uses for token lookup and rate limiting.
 - **The platform proxy handles token storage and refresh.** OAuth tokens are stored server-side by the platform. The assistant never sees or stores the Twitter OAuth access/refresh tokens in managed mode. Token refresh is handled transparently by the proxy.
 - **The daemon auth handler never starts local OAuth in managed mode.** When `integrationMode` is `managed`, `handleTwitterAuthStart` returns a managed-specific error code (`managed_auth_via_platform` or `managed_missing_api_key`) and never calls `orchestrateOAuthConnect`. This is a critical guardrail to prevent credential confusion.
 
 ### OAuth (recommended with X developer credentials)
 
-OAuth uses the official X API v2. It is the most reliable connection method and does not depend on browser sessions.
+OAuth uses the official X API v2. It is the most reliable local connection method.
 
 - Supports: **post** and **reply**
-- Read-only operations (timeline, search, home, bookmarks, notifications, likes, followers, following, media) always use the browser path directly, regardless of the strategy setting.
 - Setup: Collect the OAuth Client ID (and optional Client Secret) from the user in chat using `credential_store` with `action: "prompt"` (canonical field names: `client_id`, `client_secret`), then initiate the `twitter_auth_start` flow. See the **First-Use Decision Flow** for the full sequence.
-- Set the strategy: `assistant config set twitter.operationStrategy oauth`
-
-### Browser session (no developer credentials needed)
-
-The browser path is quick to start and useful when the user does not have X developer app credentials. It captures auth cookies from Chrome and uses them to interact with X. Chrome management uses `assistant browser chrome launch` and `assistant browser chrome minimize` CLI commands internally.
-
-- Supports: **all operations** (post, reply, timeline, search, home, bookmarks, notifications, likes, followers, following, media)
-- Setup: Run `assistant x refresh` to open Chrome and capture session cookies automatically.
-- Set the strategy: `assistant config set twitter.operationStrategy browser`
-- **Session storage**: Session cookies are stored in the encrypted credential store under the key `twitter:session:cookies`. You can inspect the stored session with `assistant credentials inspect twitter:session:cookies`.
-
-### Auto mode (default)
-
-When the strategy is `auto` (the default), the router tries OAuth first for supported operations if credentials are available, then falls back to the browser path. This gives the best of both worlds without requiring manual switching.
-
-- Set auto mode: `assistant config set twitter.operationStrategy auto`
 
 ## First-Use Decision Flow
 
-When the user triggers a Twitter operation and no strategy has been configured yet, follow these steps:
+When the user triggers a Twitter operation and no connection has been configured yet, follow these steps:
 
 1. **Check current status:**
 
    ```bash
-   # Check strategy
-   assistant config get twitter.operationStrategy
-
    # Check if OAuth token is available
    assistant oauth token twitter --json
 
-   # Check browser session
-   assistant x status --json
+   # Check integration mode
+   assistant config get twitter.integrationMode
    ```
 
-   If the strategy is not set, the user has not yet chosen a strategy and should be guided through setup.
+2. **Determine the best path:**
+   - If managed mode prerequisites are met (integration mode is `managed`, assistant is registered with the platform, API key is present, and the owner has connected their Twitter account), use managed mode.
+   - Otherwise, guide the user through OAuth setup.
 
-2. **Present both options with trade-offs:**
-   - **OAuth**: Most reliable and official. Requires X developer app credentials (OAuth Client ID and optional Client Secret). Supports posting and replying. Set up right here in the chat.
-   - **Browser session**: Quick to start, no developer credentials needed. Supports all operations including reading timelines and searching. Set up with `assistant x refresh`.
-
-3. **Ask the user which they prefer.** Do not choose for them.
-
-4. **Execute setup for the chosen path:**
+3. **Execute setup for the chosen path:**
+   - If managed: Confirm prerequisites are satisfied. Managed mode requires no local setup beyond platform registration.
    - If OAuth: Collect the credentials in-chat using the secure credential prompt, then connect. Follow the **OAuth Setup Sequence** below.
-   - If browser: Run `assistant x refresh` to capture session cookies from Chrome.
 
 ### OAuth Setup Sequence
 
-When the user chooses OAuth, collect their X developer credentials conversationally using the secure UI. The OAuth flow delegates to the generic connect orchestrator, which resolves the Twitter provider profile, computes scopes via policy, opens the X authorization page in the user's browser, verifies the user's identity, and stores tokens. The orchestrator also manages stale refresh-token cleanup and enforces integration-mode guards.
+When the user chooses OAuth, collect their X developer credentials conversationally using the secure UI. The OAuth flow delegates to the generic connect orchestrator, which resolves the Twitter provider profile, computes scopes via policy, opens the X authorization page, verifies the user's identity, and stores tokens. The orchestrator also manages stale refresh-token cleanup and enforces integration-mode guards.
 
 1. **Collect the Client ID securely:**
    Call `credential_store` with `action: "prompt"`, `service: "integration:twitter"`, `field: "client_id"`, `label: "X (Twitter) OAuth Client ID"`, `description: "Enter the Client ID from your X Developer App"`, and `placeholder: "your-client-id"`.
@@ -100,113 +74,72 @@ When the user chooses OAuth, collect their X developer credentials conversationa
    Ask the user if their X app uses a confidential client (has a Client Secret). If yes, call `credential_store` with `action: "prompt"`, `service: "integration:twitter"`, `field: "client_secret"`, `label: "X (Twitter) OAuth Client Secret"`, `description: "Enter the Client Secret from your X Developer App (leave blank if using a public client)"`, and `placeholder: "your-client-secret"`.
 
 3. **Initiate the OAuth flow:**
-   Trigger the Twitter auth start flow. The connect orchestrator resolves the Twitter provider profile, computes scopes via policy, opens the X authorization page in the user's browser, verifies the user's identity, and stores tokens. Wait for the auth result.
+   Trigger the Twitter auth start flow. The connect orchestrator resolves the Twitter provider profile, computes scopes via policy, opens the X authorization page, verifies the user's identity, and stores tokens. Wait for the auth result.
 
 4. **Confirm success:**
    Tell the user: "Great, your X account is connected! You can always update these credentials from the Settings page."
 
-5. **Set the preferred strategy:**
-   ```bash
-   assistant config set twitter.operationStrategy <oauth|browser|auto>
-   ```
-
 ## Failure Recovery Flow
 
 When a Twitter operation fails, follow these steps:
 
 1. **Detect the failure type from the error output:**
-   - `session_expired` or `SessionExpiredError` — the browser session cookies have expired.
-   - `OAuth is not configured` — the user chose OAuth but credentials are not set up.
-   - `Twitter API error (401)` — OAuth token may be expired or revoked.
-   - `UnsupportedOAuthOperationError` — the requested write operation is not available via OAuth.
-   - `Cannot connect to assistant` — the Vellum assistant is not running.
-   - `proxyErrorCode: "owner_credential_required"` — managed mode: the assistant owner has not connected their X account on the platform.
-   - `proxyErrorCode: "owner_only"` — managed mode: the current user is not the assistant owner.
-   - `proxyErrorCode: "auth_failure"` or `"upstream_failure"` — managed mode: platform token issue, reconnect Twitter on the platform.
-   - `proxyErrorCode: "missing_assistant_api_key"` — managed mode: the assistant is not bootstrapped.
-   - `proxyErrorCode: "missing_platform_assistant_id"` — managed mode: the assistant is not registered with the platform.
+   - `OAuth is not configured` -- the user chose OAuth but credentials are not set up.
+   - `Twitter API error (401)` -- OAuth token may be expired or revoked.
+   - `Cannot connect to assistant` -- the Vellum assistant is not running.
+   - `proxyErrorCode: "owner_credential_required"` -- managed mode: the assistant owner has not connected their X account on the platform.
+   - `proxyErrorCode: "owner_only"` -- managed mode: the current user is not the assistant owner.
+   - `proxyErrorCode: "auth_failure"` or `"upstream_failure"` -- managed mode: platform token issue, reconnect Twitter on the platform.
+   - `proxyErrorCode: "missing_assistant_api_key"` -- managed mode: the assistant is not bootstrapped.
+   - `proxyErrorCode: "missing_platform_assistant_id"` -- managed mode: the assistant is not registered with the platform.
 
 2. **Explain the likely cause clearly** to the user.
 
-3. **Suggest trying the other path as an alternative:**
-   - If the browser session expired: suggest setting up OAuth for post/reply operations, or refresh the browser session with `assistant x refresh`.
-   - If OAuth failed or is not configured: suggest using the browser path with `assistant config set twitter.operationStrategy browser` and `assistant x refresh`.
-   - If the operation is unsupported via OAuth: explain that this write operation is not yet supported via OAuth, and suggest using the browser path with `assistant config set twitter.operationStrategy browser`.
+3. **Suggest recovery steps:**
+   - If OAuth failed or is not configured: suggest reconnecting OAuth credentials or checking that the X developer app credentials are correct.
    - If managed mode failed with a credential or ownership error: explain the specific issue and guide the user to resolve it on the platform (connect Twitter, sign in as owner, etc.).
 
-4. **Offer concrete steps to switch:**
-
-   ```bash
-   # Switch to the other strategy
-   assistant config set twitter.operationStrategy <oauth|browser|auto>
-
-   # If switching to browser, refresh the session
-   assistant x refresh
-   ```
-
-## Strategy Management Commands
-
-```bash
-# Check current strategy
-assistant config get twitter.operationStrategy
-
-# Set strategy to OAuth, browser, or auto
-assistant config set twitter.operationStrategy oauth
-assistant config set twitter.operationStrategy browser
-assistant config set twitter.operationStrategy auto
-
-# Check full status (session, OAuth, and strategy info)
-assistant x status --json
-```
-
 ## Posting
 
-Before posting, check the integration mode and fetch the current strategy:
+Before posting, check the integration mode:
 
 ```bash
-# 1. Check integration mode
 MODE=$(assistant config get twitter.integrationMode)
-
-# 2. Get the configured strategy
-STRATEGY=$(assistant config get twitter.operationStrategy)
-# If not set, default to "auto"
 ```
 
-Then post based on the mode and strategy:
+Then post based on the mode:
 
 ```bash
-# Managed mode — route through platform proxy (no local token needed):
-assistant x post "The post text here" --strategy managed
+# Managed mode -- route through platform proxy (no local token needed):
+assistant x post "The post text here" --managed
 
-# With OAuth token (strategy is oauth or auto):
+# With OAuth token:
 TOKEN=$(assistant oauth token twitter)
-assistant x post "The post text here" --strategy "$STRATEGY" --oauth-token "$TOKEN"
-
-# With browser-only strategy:
-assistant x post "The post text here" --strategy browser
+assistant x post "The post text here" --oauth-token "$TOKEN"
 ```
 
-When `twitter.integrationMode` is `managed`, always use `--strategy managed`. The platform proxy handles authentication.
+When `twitter.integrationMode` is `managed`, always use `--managed`. The platform proxy handles authentication.
 
 Returns JSON with `ok`, `tweetId`, `text`, `url`, and `pathUsed` fields. Share the URL with the user so they can verify the post. For managed mode errors, the response includes `proxyErrorCode` and `retryable` fields.
 
 ## Replying
 
-Same setup as posting — check integration mode and fetch strategy first, then:
+Same setup as posting -- check integration mode first, then:
 
 ```bash
 # Managed mode:
-assistant x reply <tweetUrl> "The reply text here" --strategy managed
+assistant x reply <tweetUrl> "The reply text here" --managed
 
-# Local OAuth or auto:
-assistant x reply <tweetUrl> "The reply text here" --strategy "$STRATEGY" --oauth-token "$TOKEN"
+# Local OAuth:
+TOKEN=$(assistant oauth token twitter)
+assistant x reply <tweetUrl> "The reply text here" --oauth-token "$TOKEN"
 ```
 
 The first argument is a tweet URL (e.g. `https://x.com/user/status/123456`) or a bare tweet ID.
 
 ## Reading
 
-Read-only operations always use the browser path directly, regardless of the strategy setting. They work the same whether the strategy is `oauth`, `browser`, or `auto` — the strategy only affects `post` and `reply` commands.
+Read operations are available in managed mode. They route through the platform proxy.
 
 ### User timeline
 
@@ -227,65 +160,21 @@ Returns the focal tweet and its reply thread.
 ### Search
 
 ```bash
-assistant x search "query" [--count N] [--product Top|Latest|People|Media]
+assistant x search "query" [--product Top|Latest|People|Media]
 ```
 
-### Home timeline
-
-```bash
-assistant x home [--count N]
-```
-
-### Bookmarks
-
-```bash
-assistant x bookmarks [--count N]
-```
-
-### Notifications
-
-```bash
-assistant x notifications [--count N]
-```
-
-Returns `notifications` array with `id`, `message`, `timestamp`, `url`.
-
-### Likes
-
-```bash
-assistant x likes <screenName> [--count N]
-```
-
-### Followers / Following
-
-```bash
-assistant x followers <screenName> [--count N]
-assistant x following <screenName> [--count N]
-```
-
-Returns `user` and `followers`/`following` array (userId, screenName, name).
-
-### Media
-
-```bash
-assistant x media <screenName> [--count N]
-```
-
-Returns tweets that contain media from the user's profile.
-
 ## Workflows
 
 ### Check Mentions
 
 When the user asks to check mentions, check X, or see what's happening:
 
-1. Fetch notifications: `assistant x notifications --count 20 --json`
-2. Fetch their recent tweets to see replies: `assistant x timeline <theirScreenName> --count 10 --json`
-3. Summarize what needs attention:
-   - Group by type: replies to their tweets, likes, new followers, mentions
+1. Fetch their recent tweets to see replies: `assistant x timeline <theirScreenName> --count 10 --json`
+2. Summarize what needs attention:
+   - Group by type: replies to their tweets, mentions
    - For anything that looks like it needs a reply, fetch the full thread with `assistant x tweet <tweetId>` to understand context
-   - Prioritize: direct questions > mentions > engagement notifications
-4. For items that need replies, draft a response and ask the user to approve before sending with `assistant x reply`
+   - Prioritize: direct questions > mentions > engagement
+3. For items that need replies, draft a response and ask the user to approve before sending with `assistant x reply`
 
 Present the summary as a scannable list, not a wall of text. Lead with action items.
 
@@ -304,16 +193,14 @@ When the user wants to see how their posts are performing:
 
 1. Fetch their recent tweets: `assistant x timeline <screenName> --count 20 --json`
 2. For each tweet, note engagement signals from the text/metadata
-3. Fetch notifications to see who's interacting: `assistant x notifications --count 20 --json`
-4. Summarize: which posts got traction, who's engaging, any conversations worth continuing
+3. Summarize: which posts got traction, who's engaging, any conversations worth continuing
 
 ## Tips
 
 - Keep posts under 280 characters
 - All `screenName` arguments should be without the `@` prefix
 - All commands return JSON with an `ok` field
-- When drafting replies, match the tone of the conversation — casual threads get casual replies
+- When drafting replies, match the tone of the conversation -- casual threads get casual replies
 - Always show the user what you're about to post and get approval before sending
-- If a browser session is expired, refresh it with `assistant x refresh` before retrying, or suggest switching to OAuth for post/reply operations
 - If an operation fails, check `assistant x status --json` to diagnose the issue before retrying
 - The `post` and `reply` commands include a `pathUsed` field in their response so you can tell the user which connection method was used

package/src/config/feature-flag-registry.json

@@ -104,6 +104,14 @@
       "label": "App Builder Multi-file",
       "description": "Enable multi-file TSX app creation with esbuild compilation instead of single-HTML apps",
       "defaultEnabled": false
+    },
+    {
+      "id": "sentry-testing",
+      "scope": "macos",
+      "key": "sentry_testing_enabled",
+      "label": "Sentry Testing",
+      "description": "Show the Sentry Testing tab in Settings for triggering test crash reports and error events",
+      "defaultEnabled": false
     }
   ]
 }

package/src/daemon/handlers/session-history.ts

@@ -27,6 +27,43 @@ import {
   renderHistoryContent,
 } from "./shared.js";
 
+/**
+ * In light mode, strip heavy payloads (e.g. full HTML) from surface data
+ * but preserve the fields the client needs to parse and render the surface.
+ */
+function lightModeSurfaceData(s: HistorySurface): Record<string, unknown> {
+  switch (s.surfaceType) {
+    case "dynamic_page":
+      return {
+        ...(s.data.preview ? { preview: s.data.preview } : {}),
+        ...(s.data.appId ? { appId: s.data.appId } : {}),
+      };
+    case "card":
+      return {
+        ...(typeof s.data.title === "string" ? { title: s.data.title } : {}),
+        ...(typeof s.data.body === "string" ? { body: s.data.body } : {}),
+        ...(typeof s.data.template === "string"
+          ? { template: s.data.template }
+          : {}),
+        ...(s.data.templateData ? { templateData: s.data.templateData } : {}),
+      };
+    case "document_preview":
+      return {
+        ...(typeof s.data.surfaceId === "string"
+          ? { surfaceId: s.data.surfaceId }
+          : {}),
+        ...(typeof s.data.title === "string" ? { title: s.data.title } : {}),
+        ...(typeof s.data.content === "string"
+          ? { content: s.data.content }
+          : {}),
+      };
+    default:
+      // For other types (list, table, form, confirmation, etc.),
+      // preserve the full data — these are generally small.
+      return s.data;
+  }
+}
+
 export function handleHistoryRequest(
   msg: HistoryRequest,
   ctx: HandlerContext,
@@ -190,7 +227,9 @@ export function handleHistoryRequest(
             })
         : m.toolCalls;
 
-    // In light mode, strip full data from surfaces (keep metadata)
+    // In light mode, strip heavy payloads but keep essential fields so
+    // the client can still parse and render surfaces (e.g. card title/body,
+    // dynamic_page preview, document_preview metadata).
     const filteredSurfaces =
       m.surfaces.length > 0
         ? includeSurfaceData
@@ -199,14 +238,7 @@ export function handleHistoryRequest(
               surfaceId: s.surfaceId,
               surfaceType: s.surfaceType,
               title: s.title,
-              data: {
-                ...(s.surfaceType === "dynamic_page"
-                  ? {
-                      ...(s.data.preview ? { preview: s.data.preview } : {}),
-                      ...(s.data.appId ? { appId: s.data.appId } : {}),
-                    }
-                  : {}),
-              } as Record<string, unknown>,
+              data: lightModeSurfaceData(s),
               ...(s.actions ? { actions: s.actions } : {}),
               ...(s.display ? { display: s.display } : {}),
             }))

package/src/daemon/lifecycle.ts

@@ -93,7 +93,10 @@ import {
   registerMessagingProviders,
   registerWatcherProviders,
 } from "./providers-setup.js";
-import { handleRideShotgunStart, handleRideShotgunStop } from "./ride-shotgun-handler.js";
+import {
+  handleRideShotgunStart,
+  handleRideShotgunStop,
+} from "./ride-shotgun-handler.js";
 import { seedInterfaceFiles } from "./seed-files.js";
 import { DaemonServer } from "./server.js";
 import { initSlashPairingContext } from "./session-slash.js";
@@ -439,23 +442,7 @@ export async function runDaemon(): Promise<void> {
           undoLastMessage(sessionId, server.getHandlerContext()),
         regenerateResponse: (sessionId) => {
           let hubChain: Promise<void> = Promise.resolve();
-          const session = server
-            .getHandlerContext()
-            .sessions.get(sessionId);
           const sendEvent = (event: ServerMessage) => {
-            // Skip state-signal events only when the session has an
-            // onStateSignal listener wired (set in conversation-routes.ts),
-            // since that listener already publishes them to the hub.
-            // Without the listener (e.g. IPC-originated sessions regenerated
-            // via HTTP), we must let these events through to avoid silent loss.
-            if (
-              session?.hasStateSignalListener &&
-              "type" in event &&
-              (event.type === "assistant_activity_state" ||
-                event.type === "confirmation_state_changed")
-            ) {
-              return;
-            }
             const ae = buildAssistantEvent(
               DAEMON_INTERNAL_ASSISTANT_ID,
               event,

package/src/daemon/message-types/apps.ts

@@ -18,12 +18,6 @@ export interface AppsListRequest {
   type: "apps_list";
 }
 
-export interface HomeBaseGetRequest {
-  type: "home_base_get";
-  /** If true, daemon ensures a durable Home Base link exists before responding. */
-  ensureLinked?: boolean;
-}
-
 export interface AppOpenRequest {
   type: "app_open_request";
   appId: string;
@@ -176,23 +170,6 @@ export interface AppsListResponse {
   }>;
 }
 
-export interface HomeBaseGetResponse {
-  type: "home_base_get_response";
-  homeBase: {
-    appId: string;
-    source: string;
-    starterTasks: string[];
-    onboardingTasks: string[];
-    preview: {
-      title: string;
-      subtitle: string;
-      description: string;
-      icon: string;
-      metrics: Array<{ label: string; value: string }>;
-    };
-  } | null;
-}
-
 export interface SharedAppsListResponse {
   type: "shared_apps_list_response";
   apps: Array<{
@@ -361,7 +338,6 @@ export interface AppFilesChanged {
 export type _AppsClientMessages =
   | AppDataRequest
   | AppsListRequest
-  | HomeBaseGetRequest
   | AppOpenRequest
   | SharedAppsListRequest
   | AppDeleteRequest
@@ -386,7 +362,6 @@ export type _AppsClientMessages =
 export type _AppsServerMessages =
   | AppDataResponse
   | AppsListResponse
-  | HomeBaseGetResponse
   | SharedAppsListResponse
   | AppDeleteResponse
   | SharedAppDeleteResponse

package/src/daemon/message-types/integrations.ts

@@ -36,13 +36,10 @@ export interface TwitterIntegrationConfigRequest {
     | "set_mode"
     | "set_local_client"
     | "clear_local_client"
-    | "disconnect"
-    | "get_strategy"
-    | "set_strategy";
+    | "disconnect";
   mode?: "local_byo" | "managed";
   clientId?: string;
   clientSecret?: string;
-  strategy?: string;
 }
 
 export interface TelegramConfigRequest {
@@ -159,9 +156,6 @@ export interface TwitterIntegrationConfigResponse {
   localClientConfigured: boolean;
   connected: boolean;
   accountInfo?: string;
-  strategy?: "oauth" | "browser" | "auto";
-  /** Whether the user has explicitly set a strategy (vs. relying on the default 'auto'). */
-  strategyConfigured?: boolean;
   error?: string;
 }
 

package/src/daemon/message-types/sessions.ts

@@ -304,7 +304,12 @@ export interface HistoryResponseSurface {
   surfaceType: string;
   title?: string;
   data: Record<string, unknown>;
-  actions?: Array<{ id: string; label: string; style?: string }>;
+  actions?: Array<{
+    id: string;
+    label: string;
+    style?: string;
+    data?: Record<string, unknown>;
+  }>;
   display?: string;
 }
 

package/src/daemon/message-types/surfaces.ts

@@ -23,6 +23,8 @@ export interface SurfaceAction {
   id: string;
   label: string;
   style?: "primary" | "secondary" | "destructive";
+  /** Optional data payload returned to the daemon when this action is clicked. */
+  data?: Record<string, unknown>;
 }
 
 export interface CardSurfaceData {