@2nd1st/dsh-plugin-open-app

LIMITATIONS

Known limitations

- **The opening line is one model call per app.** See above; `installMessage: ''` opts out, at the cost of the blank-session layout and of the strip's first receipt. The rules are unaffected — they are a system section, and `containerPrompt: ''` is what retires those. - **A container that never got its opening line has no tab ring.** dsh renders no view until a session has its first message. Until then the app renders in a row of its own above the composer (`conversation.input.dock`) — live and interactive, never covering the input — and moves into the Apps tab the instant the ring appears. - **An app's conversations are hidden from the session tree, not just its workspace.** Hiding the workspace alone would drop its sessions into the Ungrouped bucket, so they are hidden with it (through dsh's own archived-session set, in this client's projection only — nothing is archived on the host). They are still reachable the way they are meant to be: through the app. - **The App Store's "open" needs an engine that knows `?nav=intent`** (v0.5.1+). An older engine ignores the parameter, and the store's links navigate its own frame instead of entering the other app's container. - **An app taller than the panel needs an engine that keeps its viewer scrollable.** The panel gives every app the same height, and an app whose document is taller than that has to scroll inside it. Seven of the shipped apps declare `html,body{overflow:hidden}` — correct advice to a host that sizes the frame from the app, and in a fixed frame it means the wheel does nothing (measured: habit-streaks at 1712×537, document 1127px, nothing in the tree scrollable, 590px unreachable). The engine's viewer (v0.5.1+) sets `overflow-y:auto` on the root of a standalone page, which costs nothing when the app fits — on an older engine those apps are clipped at the fold, in a browser tab exactly as in this panel. - **A sandboxed app's links are not intercepted.** Apps installed `--sandboxed` run in the runner's own child document; the click interception lives in the document the engine serves. Every app the AI writes, and everything from the App Store, is local and covered. - **The Apps section sits at the foot of the sidebar, not above the workspace list.** The sidebar shell offers plugins exactly one hole (`sidebar.footer.action`, below the workspace region); the region itself is a single-occupant slot that dsh's own workspace browser fills, and registering a second entry there would shadow it rather than sit beside it. - **Chat stays dsh's default view.** The Apps tab sorts first, but a session with no stored preference opens on Chat — the fallback is a constant inside ui-conversation. Entering through an app node selects the Apps tab explicitly, and so does the handover when a container's first message lands. - **A per-app `open_<name>` tool for an app made mid-session needs a dsh restart — and the plugin is no longer the reason.** Keyed slots take no wildcards, so the plugin asks the engine which `open_*` tools it publishes and registers each one; it now re-asks whenever the directory is opened or a card shows an app it has not heard of, so its key set is never older than the app list beside it. What does not move is dsh's own tool table: the engine registers the new tool when `save_app` runs (with `OMA_DYNAMIC_TOOLS=1`) and dsh's MCP client re-syncs on `notifications/tools/list_changed`, but the engine's `/mcp` face is stateless — `createMcpHandler` builds a fresh engine per request — so there is no live session to send that notification on. Measured on the rig: an app created in turn 1 was still missing from the model's tools in turn 2 (*"There is no tool named open_mood_tracker"*), and the session log carries exactly one `request/header` for the whole session, so the catalog never changed. None of this reaches the user, because the universal `open_app` covers every app the moment it exists