apps/web/src/lib/desktop-links.ts (1)

90-108: Consider using the generated SDK instead of raw fetch.

The coding guidelines state that frontend code must use the generated SDK from apps/web/lib/api/ rather than raw fetch. If a client for /api/internal/desktop/shell-open doesn't exist yet, consider generating one or adding this endpoint to the SDK.

Additionally, the current logic falls back to the host bridge when the controller returns a non-OK response (e.g., 403 for disallowed paths). This means a security restriction from the controller is silently bypassed via the host bridge. If this is intentional (to support paths outside the allowlist on the desktop), consider adding a comment clarifying the design decision.

As per coding guidelines: "Frontend must use generated SDK from apps/web/lib/api/, never raw fetch"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/web/src/lib/desktop-links.ts` around lines 90 - 108, Replace the raw
fetch call to "/api/internal/desktop/shell-open" with the generated SDK client
from apps/web/lib/api (use the SDK method that maps to this POST endpoint)
instead of fetch; keep the same JSON payload ({ path: folderPath }) and await
the SDK response. After calling the SDK, explicitly handle non-OK responses: do
not silently fall back to hostBridge.invoke("shell:open-external", { url }) when
the controller returns a non-OK status (e.g., 403); either return/throw the
error or add a clear comment above the hostBridge fallback that this bypass is
intentional and why. Ensure you reference and update the code paths that use
folderPath, hostBridge, and url so the SDK call replaces the existing fetch and
the fallback behavior is made explicit.

apps/controller/src/routes/desktop-routes.ts (1)

101-112: Redundant allowlist check – allowedWorkspaceRoot is already inside allowedRoot.

Since allowedWorkspaceRoot is defined as path.join(container.env.openclawStateDir, "agents"), any path that passes the workspace root check will also pass the allowedRoot check. The workspace-specific conditions at lines 110-111 are always subsumed by lines 108-109.

If the intent is to restrict shell-open to only the agents subdirectory (not the broader state dir), consider using only allowedWorkspaceRoot. If both should be allowed, the current code works but the workspace checks can be removed for clarity.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/controller/src/routes/desktop-routes.ts` around lines 101 - 112, The
checks are redundant because allowedWorkspaceRoot
(path.join(container.env.openclawStateDir, "agents")) is inside allowedRoot;
either remove the workspace-specific conditions (the
resolved.startsWith(allowedWorkspaceRoot + path.sep) and resolved ===
allowedWorkspaceRoot checks) to keep the broader allowlist, or if you intend to
restrict to only the agents subdirectory, change allowedRoot to point to
allowedWorkspaceRoot and remove the separate allowedWorkspaceRoot variable and
checks; update the conditional that checks resolved accordingly (references:
allowedRoot, allowedWorkspaceRoot, resolved, container.env.openclawStateDir).

apps/controller/tests/route-compat.test.ts (1)

294-309: Consider adding a test for the no-bots fallback path.

The test covers the happy path where a bot exists. To fully exercise the updated /api/internal/desktop/ready endpoint, consider adding a second test case that omits the createBot call and asserts workspacePath equals path.join(rootDir, ".openclaw", "agents").

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/controller/tests/route-compat.test.ts` around lines 294 - 309, Add a new
test for the no-bots fallback of the /api/internal/desktop/ready endpoint: copy
the existing it(...) block but do NOT call container.configStore.createBot;
create the app with createApp(container), request "/api/internal/desktop/ready",
assert status 200, parse payload and assert payload.workspacePath ===
path.join(rootDir, ".openclaw", "agents") so the handler returns the default
agents directory when no bot exists (use the same test utilities and names as
the existing test for consistency).

apps/controller/src/runtime/sessions-runtime.ts (2)

416-425: Clarify intent: unknown block types are pushed but don't contribute to visibility.

Lines 422-423 push unknown block types to normalizedBlocks but don't set hasVisibleContent = true. This means a message containing only unknown block types returns null, even though those blocks are collected.

If this is intentional (only text and tool blocks count as "visible"), consider adding a brief comment. If unknown blocks should also count as visible, add hasVisibleContent = true after line 422.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/controller/src/runtime/sessions-runtime.ts` around lines 416 - 425, The
loop currently pushes blocks with unknown blockType into normalizedBlocks but
doesn't set hasVisibleContent, causing a collection of only-unknown blocks to
return null; decide whether unknown blocks should count as visible and either
(A) add hasVisibleContent = true immediately after the
normalizedBlocks.push(block) for unknown types so they mark the message as
visible, or (B) leave behavior and add an inline comment near the
normalizedBlocks.push(block) explaining that only "text" and tool types are
considered visible and unknown types are intentionally excluded from
hasVisibleContent; refer to blockType, normalizedBlocks, and hasVisibleContent
in your change.

---

483-496: Consider case-insensitive comparison for channelType.

The comparison channelType !== "feishu" is case-sensitive. While channelTypeSchema enforces lowercase "feishu" for channels, createSessionSchema accepts any string for channelType (as noted in the relevant code snippets). If a session somehow has "Feishu" or "FEISHU", the Feishu-specific stripping won't apply.

Since all current Feishu channels use lowercase (per connectFeishu()), this is a minor robustness concern rather than an active bug.

🛡️ Optional: normalize channelType comparison

   private stripChannelSystemSuffix(
     text: string,
     channelType?: string | null,
   ): string {
-    if (channelType !== "feishu") {
+    if (channelType?.toLowerCase() !== "feishu") {
       return text;
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/controller/src/runtime/sessions-runtime.ts` around lines 483 - 496, In
stripChannelSystemSuffix, the channelType comparison is case-sensitive; update
the check to handle case-insensitive values (and null/undefined) by normalizing
channelType before comparison (e.g., use channelType?.toLowerCase() === "feishu"
or similar) so Feishu-specific stripping in stripChannelSystemSuffix applies
even if channelType is "Feishu" or "FEISHU".

apps/web/src/pages/sessions.tsx (1)

773-781: extractMessage is invoked twice per displayed message.

The filter calls extractMessage for each message, then ChatBubble calls it again during render. Consider memoizing or pre-extracting once to avoid redundant parsing.

Potential optimization

-              {messages
-                .filter((msg) => {
-                  const { text, replyContextText, hasToolCall } =
-                    extractMessage(msg as unknown as Record<string, unknown>);
-                  return (
-                    text.trim().length > 0 ||
-                    (replyContextText?.trim().length ?? 0) > 0 ||
-                    hasToolCall
-                  );
-                })
-                .map((msg) => (
-                  <ChatBubble key={msg.id} msg={msg} />
-                ))}
+              {messages
+                .map((msg) => ({
+                  msg,
+                  extracted: extractMessage(msg as unknown as Record<string, unknown>),
+                }))
+                .filter(({ extracted }) =>
+                  extracted.text.trim().length > 0 ||
+                  (extracted.replyContextText?.trim().length ?? 0) > 0 ||
+                  extracted.hasToolCall
+                )
+                .map(({ msg, extracted }) => (
+                  <ChatBubble key={msg.id} msg={msg} extracted={extracted} />
+                ))}

This would require updating ChatBubble to accept an optional pre-computed extracted prop.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/web/src/pages/sessions.tsx` around lines 773 - 781, The filter currently
calls extractMessage for each message and ChatBubble calls extractMessage again
during render, causing duplicate work; fix by pre-extracting once in the mapping
step (e.g., create an array of {msg, extracted: extractMessage(msg)} before
filtering) and update ChatBubble to accept an optional extracted prop (e.g.,
extracted) so you can pass the precomputed result into ChatBubble instead of
letting it call extractMessage again; ensure all call sites of ChatBubble are
updated to prefer the extracted prop when present and keep extractMessage usage
only where no precomputed value exists.

apps/web/tests/sessions.test.tsx (1)

405-417: Consider extracting a shared test harness for repeated QueryClient setup.

The new cases repeat the same initialization boilerplate; a small helper would reduce noise and future maintenance overhead.

Also applies to: 462-476, 528-543

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/web/tests/sessions.test.tsx` around lines 405 - 417, Extract the
repeated QueryClient initialization and pre-population into a small test helper
(e.g., createTestQueryClient or setupQueryClientWithSessionMeta) that constructs
a QueryClient with defaultOptions.queries.retry = false and calls
queryClient.setQueryData(["session-meta", sessionId], { id: sessionId, title,
channelType, messageCount, ... }) before returning the client; replace the
duplicated blocks that call new QueryClient(...) and setQueryData in tests (the
code using QueryClient and setQueryData) with calls to this helper to reduce
boilerplate and ensure consistent setup across test cases.