feat(app-core): apps open in dedicated native windows (Ghost-style)

[Dexploarer]

Summary

• Every app — internal tool, overlay, registry/catalog — launches in its own Electrobun BrowserWindow with slug-based dedupe and persisted bounds.
• New AppWindowRenderer mounts only the app's content (no surrounding shell chrome) at /apps/<slug> when appWindow=1.
• Application menu and tray now expose every known app via a single Apps menu (replaces per-surface menus).
• <scheme>://apps/<slug> deep links open or focus the matching app window.

Architecture

Renderer

• AppWindowRenderer (new): three-branch full-bleed component that resolves the slug to one of (a) lazy-loaded internal-tool tab component, (b) overlay app's Component, (c) catalog app's viewer iframe with postMessage auth handshake.
• AppsView.handleLaunch in Electrobun mode always routes through openAppRouteWindow (no fallback to in-shell iframe attach).
• internal-tool-apps declares an explicit windowPath per tool; new getInternalToolAppWindowPath / getInternalToolAppDescriptors exposed.
• Foundation files added (not yet wired): per-app-config.ts, launch-history.ts for the upcoming AppDetailsView.

Bun

• desktopOpenAppWindow accepts slug; threaded through DesktopManager → SurfaceWindowManager → ManagedWindowRecord.
• Slug-based dedupe in createManagedWindow focuses an existing window instead of spawning a duplicate.
• Per-slug bounds persistence via injected BoundsStore (concrete fs implementation lives in milady root). Saved frame restored on slug match; debounced 500ms saves on resize/move.
• Per-surface submenus replaced with a unified Apps menu; bun-side APP_MENU_ENTRIES mirror keeps the renderer module out of the bun bundle.
• Tray gains one entry per app (tray-app-<slug>), routed through handleApplicationMenuAction.
• setupDeepLinks recognizes <scheme>://apps/<slug> and opens the matching window via findAppMenuEntryBySlug + getDesktopManager().openAppWindow.

Test plan

• Click any app in AppsView → opens in its own native window with no Milady shell chrome
• Re-clicking same app focuses existing window (no duplicate)
• Resize/move an app window, close it, relaunch → restores last bounds
• Apps menu shows every app; clicking opens its window
• Tray menu shows every app; clicking opens its window
• open elizaos://apps/plugins from terminal opens Plugin Viewer
• Web fallback (open in browser) still uses iframe + sidebar tab path
• Catalog/registry app windows show launch viewer iframe with auth handshake
• Overlay (companion) opens in its own window with exitToApps closing the window

[codereviewbot-ai]

Potential Security Issue:
The gatePluginSessionForHostedApp function wraps the plugin for session gating. If this function does not enforce strict session validation or access control, it could allow unauthorized access to the plugin's services and actions. Ensure that gatePluginSessionForHostedApp implements robust session validation and restricts access appropriately.

Recommended Solution:
Review the implementation of gatePluginSessionForHostedApp to confirm it enforces proper authentication and authorization checks for hosted app sessions.

[codereviewbot-ai]

Type Re-export Risk:
The statement export type * from "./sdk/types.js"; re-exports all types from the SDK. This can unintentionally expose internal or sensitive types, or cause naming conflicts if types are not carefully managed.

Recommended Solution:
Consider explicitly exporting only the necessary types to avoid accidental exposure or conflicts:

export type { SpecificType1, SpecificType2 } from "./sdk/types.js";

[codereviewbot-ai]

There is no validation for the presence of app or app.name. If app is undefined or does not have a name property, this will result in a runtime error. Consider adding a conditional check or fallback value to ensure robustness:

<TwoThousandFourScapeOperatorSurface appName={app?.name ?? ""} variant="detail" />

[codereviewbot-ai]

Potential race condition in sendOperatorMessage:

The sending state is checked before the async operation, but since React state updates are asynchronous, there is a risk that multiple calls to sendOperatorMessage could bypass the check and execute concurrently. This could result in multiple operator messages being sent unintentionally.

Recommended solution:
Consider using a ref to track the sending state, or disabling the UI trigger (e.g., the Send button) immediately upon invocation to ensure only one message is sent at a time.

const sendingRef = useRef(false);
const sendOperatorMessage = useCallback(async (content: string) => {
  if (!run || content.length === 0 || sendingRef.current) return false;
  sendingRef.current = true;
  ...
  finally {
    sendingRef.current = false;
  }
}, [run]);

[codereviewbot-ai]

Missing check for run.runId in handleControl:

In the handleControl function, there is no check to ensure that run.runId is defined before calling client.controlAppRun. If run.runId is undefined, this could result in an error or unintended behavior.

Recommended solution:
Add a check for run.runId before invoking the client method:

if (!run || !run.runId) return;

[codereviewbot-ai]

Insufficient input validation for command content

In the POST /message handler, the code checks if body.content is a non-empty string, but does not perform further validation or sanitization. This could allow malicious or malformed input to be processed downstream, potentially leading to security issues or unexpected behavior.

Recommendation:

• Implement stricter validation and sanitization of user input before processing or forwarding commands. Consider using a schema validation library (e.g., zod, joi) to enforce expected structure and content.

[codereviewbot-ai]

The component assumes that the app prop and its name property are always defined. If app is undefined or does not contain a name, this will result in a runtime error. Consider adding a guard clause or fallback value to handle cases where app or app.name may be missing:

if (!app || !app.name) return null; // or display an error message

This will improve the component's robustness and prevent potential runtime exceptions.

[codereviewbot-ai]

Potential race condition in sendCommand

The check for sendingCommand before sending a command is not atomic with the state update. If a user triggers multiple sends in rapid succession (e.g., by double-clicking the send button), it is possible for multiple commands to be sent before sendingCommand is set, leading to duplicate or out-of-order commands. To mitigate this, consider using a ref to track the sending state synchronously, or disable the send button immediately upon initiation of the send operation.

Recommended solution:

const sendingRef = useRef(false);

const sendCommand = useCallback(async (content: string, clearDraftOnSuccess = false) => {
  if (sendingRef.current) return;
  sendingRef.current = true;
  // ...
  try {
    // ...
  } finally {
    sendingRef.current = false;
  }
}, [/* dependencies */]);

This ensures that the sending state is checked and set synchronously, preventing race conditions.

[codereviewbot-ai]

Assumption about updatedAt in replaceRun

The replaceRun function sorts runs by updatedAt using localeCompare, assuming that updatedAt is always a valid string. If updatedAt is missing or not a valid ISO string, this could result in incorrect sorting and potentially display the wrong run as the most recent.

Recommended solution:
Add a fallback or validation for updatedAt:

.sort((left, right) => {
  const leftDate = left.updatedAt || '';
  const rightDate = right.updatedAt || '';
  return rightDate.localeCompare(leftDate);
});

Or, if possible, ensure that updatedAt is always present and valid at the data source.

[codereviewbot-ai]

Lack of error handling for registration calls

The calls to registerOperatorSurface and registerDetailExtension are made without any error handling. If these functions throw exceptions or fail, the module could fail to load, potentially impacting application stability.

Recommended solution:
Wrap the registration calls in a try-catch block to handle potential errors gracefully:

try {
  registerOperatorSurface("@clawville/app-clawville", ClawvilleOperatorSurface);
  registerDetailExtension("clawville-control", ClawvilleDetailExtension);
} catch (error) {
  // Handle or log the error appropriately
}

[Dexploarer]

Superseded by elizaOS#7115 (org fork → upstream).