Platform & Feature Status

The canonical, evidence-backed status of Murasaki features on macOS, Windows, and Linux.

Murasaki is pre-1.0 software. Some parts are ready to use, some have meaningful platform gaps, and others are designs rather than shipping APIs. This page is generated from packages/murasaki/capabilities.json, the repository's canonical capability manifest.

Planned does not mean available. A dependency, Rust module, type, or roadmap entry is not marked as shipping until Murasaki exposes a supported path and records its limitations here.

Status definitions

Stable — shipping public surface with a compatibility commitment for the current release line.
Experimental — shipping and tested, but its API or wire contract may change before 1.0.
Partial — usable today, with a material API or platform gap described in the table.
Planned — no supported implementation is available.

Platform labels are separate from feature maturity. Dev only means the development runtime exists on that platform but there is no production packaging claim. Unavailable means that feature does not apply or has no implementation there.

Murasaki 0.52.0 · manifest schema 1

Murasaki feature and platform support
Feature	Status	macOS	Windows	Linux	Current limits
File routingWeb framework	Partial	Supported	Supported	Dev only	Page, layout, loading, error, not-found, route-group, and single dynamic segments ship today; catch-all page segments are not implemented. The router is client-side and does not provide the full Next.js App Router or React Server Components runtime. API and evidence API: `AppRouter`, `Link`, `useRouter`, `usePathname`, `useParams` Evidence:No automated evidence (not implemented)
Server ActionsWeb framework	Experimental	Supported	Supported	Dev only	Actions execute in the bundled local Node runtime; they are not Next.js Server Actions and are not a remotely hosted RPC service. The versioned wire format has explicit value and payload limits and may change before Murasaki 1.0. API and evidence API: `defineAction`, `callAction`, `useAction`, `ActionState` Evidence:`packages/murasaki/test/server-actions-wire.test.mjs`, `packages/murasaki/test/wire.test.mjs`
API RoutesWeb framework	Experimental	Supported	Supported	Dev only	Routes are served by the app-local Node process and are not intended to expose a public network service. The API surface follows Web Request and Response primitives but is not the complete Next.js Route Handler runtime. API and evidence API: `RouteHandler` Evidence:`packages/murasaki/test/api-routes.test.mjs`, `packages/murasaki/test/prod-server-http.test.mjs`
Navigation middlewareWeb framework	Partial	Supported	Supported	Dev only	Middleware runs in the renderer before client navigation and only receives pathname. Request headers, response headers, cookies, edge execution, and matcher configuration are not available. API and evidence API: `Middleware`, `MiddlewareContext`, `MiddlewareResult` Evidence:No automated evidence (not implemented)
Route metadataWeb framework	Partial	Supported	Supported	Dev only	Document title, description, favicon, and a small Open Graph subset are applied in the renderer. The metadata shape is not Next.js-compatible in full, and document metadata does not update the native window title. API and evidence API: `Metadata`, `GenerateMetadata`, `applyMetadata` Evidence:No automated evidence (not implemented)
Node main lifecycleApplication model	Experimental	Supported	Supported	Dev only	The src/main.ts lifecycle covers ready, cancellable beforeQuit, bounded shutdown, second-launch delivery, app paths, an AbortSignal, and typed live events to renderers in development and packaged apps. Window management is renderer-facing rather than exposed from src/main.ts; crash-restart policy and process supervision APIs are not implemented. On macOS, external Dock Quit and OS logout cannot guarantee cancellable beforeQuit through tao, although host resources and the Node child are cleaned up best-effort. API and evidence API: `murasaki/main`, `defineMain`, `emitMainEvent`, `murasaki/main-client.subscribeMainEvent`, `MainContext`, `MainDefinition` Evidence:`packages/murasaki/test/main-runtime.test.mjs`, `packages/murasaki/test/main-events.test.mjs`, `packages/murasaki/test/prod-server-http.test.mjs`
Native windowNative integration	Partial	Supported	Supported	Dev only	Primary and secondary windows can be declared, identified, shown, hidden, focused, listed, opened, and explicitly closed; runtime creation and per-window lifecycle subscriptions are not available. Window vibrancy remains a declared no-op. API and evidence API: `App`, `WindowConfig`, `SecondaryWindowConfig`, `murasaki/native.appWindow`, `murasaki/native.windows` Evidence:`packages/murasaki/test/native-api.test.mjs`, `packages/murasaki/test/windows.test.mjs`, `crates/native/src/window.rs`
Application menuNative integration	Partial	Supported	Supported	Unavailable	Native application menus ship on macOS and Windows; replacement is process-global, restricted to the primary renderer, and requires menu:application plus the capabilities of privileged roles. Linux has no default or custom application menu implementation. Missing role capabilities reject the whole replacement and keep the current menu. API and evidence API: `useAppMenu`, `AppMenu`, `AppMenuItemSpec` Evidence:`crates/native/src/webview.rs`, `crates/native/src/menu.rs`
Context menuNative integration	Partial	Supported	Supported	Unavailable	Native whole-window and scoped context menus ship on macOS and Windows behind menu:context; privileged native roles additionally require their matching capability. Menu IPC is bounded by payload, item-count, depth, and string limits. Linux has no native context-menu implementation. API and evidence API: `useContextMenu`, `ContextMenuTrigger`, `Action`, `createActions` Evidence:`crates/native/src/webview.rs`, `crates/native/src/menu.rs`
Native utilitiesNative integration	Partial	Partial	Partial	Partial	Dialogs, clipboard, notifications, shell helpers, and window controls are exposed to trusted renderer code through the same-origin native bridge and a per-window allowlist. Capabilities are command-level rather than argument/path-scoped, and the native renderer API is not available directly inside src/main.ts. API and evidence API: `murasaki/native.dialog`, `murasaki/native.clipboard`, `murasaki/native.notification`, `murasaki/native.shell`, `murasaki/native.appWindow`, `murasaki/native.app`, `murasaki/native.windows` Evidence:`packages/murasaki/test/native-api.test.mjs`, `.github/workflows/native-release.yml`
Auto-updateDistribution	Partial	Supported	Partial	Unavailable	Signed manifests, bounded downloads, SHA-256 payload verification, staged handoff, and relaunch are implemented for packaged apps. Linux packaging and updates are unavailable; Windows arm64 update publishing is not supported by the current artifact naming and manifest scan. API and evidence API: `useUpdate`, `UpdateButton`, `UpdaterConfig`, `UpdateState` Evidence:`packages/murasaki/test/updater-hardening.test.mjs`, `.github/workflows/app-package-win.yml`
Application packagingDistribution	Partial	Supported	Supported	Planned	macOS .app/.dmg and Windows portable .zip, NSIS .exe, and WiX .msi outputs ship today. Linux launcher packaging and installers are not implemented. WiX is required for MSI and only runs on Windows. API and evidence API: `murasaki bundle`, `murasaki installer` Evidence:`.github/workflows/app-package-win.yml`
Code signingDistribution	Partial	Supported	Supported	Planned	Developer ID signing and Apple notarization are wired for macOS when the developer supplies credentials. Windows Authenticode signs and verifies the application executable, portable ZIP payload, NSIS setup, and MSI through a developer-supplied PFX/store certificate or Microsoft Artifact Signing provider. Linux package signing is not implemented; ad-hoc macOS signatures do not establish user trust. API and evidence API: `MurasakiConfig.sign`, `WindowsSigningConfig`, `murasaki bundle --sign`, `murasaki installer --sign`, `murasaki installer --notarize` Evidence:`packages/murasaki/test/windows-signing.test.mjs`
Loopback endpoint protectionSecurity	Partial	Supported	Supported	Dev only	Development privileged endpoints require an HttpOnly same-site runtime session and validate loopback Host, Origin, and Fetch Metadata. Renderer native commands have a deny-by-default per-window allowlist, but argument/path/URL-scoped and multi-origin policies are not implemented. API and evidence API: No supported public API Evidence:No automated evidence (not implemented)
content-security-policySecurity	Partial	Supported	Supported	Dev only	Murasaki injects environment-specific default CSP into framework and user-owned HTML, supports a complete security.csp override or explicit opt-out, and normalizes a user-owned CSP tag to the beginning of head. The policy is delivered by meta tag, so header-only directives such as frame-ancestors, sandbox, and reporting are not enforced; CSP does not sanitize HTML or authorize Node functions, and inline styles remain enabled for compatibility. API and evidence API: `MurasakiConfig.security`, `security.csp` Evidence:`packages/murasaki/test/csp.test.mjs`, `packages/murasaki/src/vite-plugin/shell.ts`
Multi-windowApplication model	Experimental	Supported	Supported	Unavailable	Windows must be declared in configuration and are created eagerly; arbitrary runtime creation and recreation after explicit destruction are not implemented. Secondary OS/self close hides for later reopening, while an explicit parent close destroys the window until restart; the application menu remains process-global and primary-owned. API and evidence API: `MurasakiConfig.windows`, `SecondaryWindowConfig`, `WindowInfo`, `murasaki/native.appWindow.getLabel`, `murasaki/native.windows` Evidence:`packages/murasaki/test/windows.test.mjs`, `packages/murasaki/test/native-api.test.mjs`, `crates/native/src/window.rs`, `crates/native/src/launcher.rs`, `.github/workflows/ci.yml`
Tray and global shortcutsNative integration	Partial	Supported	Supported	Planned	One process-wide macOS status item / Windows system-tray icon ships with tooltip, click events, native nested menus, menu-item events, and dynamic icon/menu replacement; the latest successful create replaces the previous owner. Closing or disposing the owning renderer removes the icon. Menu roles are intentionally event-driven instead of privileged implicit actions; global shortcuts and Linux tray support are not implemented yet. API and evidence API: `murasaki/native.tray`, `TrayOptions`, `TrayMenuItem`, `TrayClickEvent` Evidence:`packages/murasaki/test/native-api.test.mjs`, `crates/native/src/webview.rs`
system-permissionsNative integration	Partial	Supported	Partial	Unavailable	Packaged macOS apps can declare camera/microphone usage descriptions, request camera, microphone, screen-recording, or accessibility consent at launch, and query/request the same permissions from a capability-gated renderer API. Windows unpackaged desktop privacy consent is usage-driven rather than an app-scoped launch prompt, so these generic calls report unsupported there; Linux is not implemented. Development requests use the terminal/Node host identity and should be tested with a packaged app. API and evidence API: `MurasakiConfig.systemPermissions`, `SystemPermissionsConfig`, `murasaki/native.systemPermission` Evidence:`packages/murasaki/test/system-permissions.test.mjs`, `crates/native/src/system_permission.rs`
Single instance and deep linksApplication model	Partial	Supported	Supported	Planned	Packaged macOS apps and installed Windows apps register declared URL schemes and file associations, preserve the per-user single-instance lock, and deliver normalized startup, second-instance, and system open requests to src/main.ts. Windows portable .zip and bare executable distributions do not register protocols or file associations automatically; registration is supplied by the NSIS and MSI installers, while Linux support remains planned. API and evidence API: `ProtocolConfig`, `FileAssociationConfig`, `OpenRequestEvent`, `OpenTarget`, `MainDefinition.openRequested`, `MainDefinition.secondInstance`, `SecondInstanceEvent` Evidence:`packages/murasaki/test/associations.test.mjs`, `packages/murasaki/test/main-runtime.test.mjs`, `packages/murasaki/test/prod-server-http.test.mjs`, `crates/native/src/launcher.rs`
Capability permissionsSecurity	Partial	Supported	Supported	Dev only	Renderer native commands are deny-by-default and granted through a runtime-validated per-window capability allowlist; sender origin and command names are validated in Rust. Argument/path scopes and explicit deny overrides are not implemented; secondary windows intentionally inherit no top-level grants, and privileged menu roles require their corresponding command capability. API and evidence API: `MurasakiConfig.capabilities`, `WindowConfig.capabilities`, `NativeCapability` Evidence:`crates/native/src/webview.rs`, `packages/murasaki/test/native-api.test.mjs`, `packages/murasaki/test/windows.test.mjs`
Linux distributionDistribution	Planned	Unavailable	Unavailable	Planned	Prebuilt Linux native binaries and development support do not constitute an installable Linux application release. AppImage, deb, rpm, repository metadata, signing, updates, and launcher packaging are not implemented. API and evidence API: No supported public API Evidence:No automated evidence (not implemented)

Reading the evidence

Open API and evidence in any row to see the supported public symbols and the automated test or workflow used as evidence. A build-only workflow proves that the code compiles on that platform; it does not turn an unexposed native helper into a supported framework API.

If implementation and this manifest disagree, treat the lower capability as the safe assumption and report the mismatch.

Platform & Feature Status

Status definitions

Reading the evidence

On this page