# What To Demo, Copy or Productize Next

> A closing scout map of the strongest reusable product ideas: composable terminal primitives, source-portable skill and hook adapters, browser-plus-terminal automation, provider-neutral remote compute, and trust-gated project actions.

- Repository: manaflow-ai/cmux
- GitHub: https://github.com/manaflow-ai/cmux
- Human wiki: https://grok-wiki.com/public/wiki/manaflow-ai-cmux-5a511656cb1a
- Complete Markdown: https://grok-wiki.com/public/wiki/manaflow-ai-cmux-5a511656cb1a/llms-full.txt

## Source Files

- `README.md`
- `CLI/cmux.swift`
- `CLI/CMUXCLI+AgentHookDefinitions.swift`
- `Sources/CmuxConfig.swift`
- `Sources/Panels/BrowserPanelView.swift`
- `Sources/TerminalController.swift`
- `web/services/vms/drivers/types.ts`
- `web/services/vms/providerGateway.ts`

---

<details>
<summary>Relevant source files</summary>
The following files were used as context for generating this wiki page:
- [README.md](README.md)
- [CLI/cmux.swift](CLI/cmux.swift)
- [CLI/CMUXCLI+AgentHookDefinitions.swift](CLI/CMUXCLI+AgentHookDefinitions.swift)
- [Sources/CmuxConfig.swift](Sources/CmuxConfig.swift)
- [Sources/CmuxActionTrust.swift](Sources/CmuxActionTrust.swift)
- [Sources/CmuxConfigExecutor.swift](Sources/CmuxConfigExecutor.swift)
- [Sources/Panels/BrowserPanelView.swift](Sources/Panels/BrowserPanelView.swift)
- [Sources/TerminalController.swift](Sources/TerminalController.swift)
- [web/services/vms/drivers/types.ts](web/services/vms/drivers/types.ts)
- [web/services/vms/drivers/index.ts](web/services/vms/drivers/index.ts)
- [web/services/vms/providerGateway.ts](web/services/vms/providerGateway.ts)
- [docs/feed.md](docs/feed.md)
- [docs/agent-browser-port-spec.md](docs/agent-browser-port-spec.md)
- [docs/internal/skills-customization-ideas.md](docs/internal/skills-customization-ideas.md)
</details>

# What To Demo, Copy or Productize Next

This page is a closing scout map: it identifies the cmux ideas most worth demoing, copying into other products, or hardening into standalone product surfaces. The strongest pattern is not a single “AI IDE” workflow. It is a set of composable primitives: native terminal surfaces, browser automation, agent hook adapters, project-defined actions, trust prompts, and provider-neutral remote compute.

The knowledge profile for this run was applied as wiki-shaping guidance only. No `STRATEGY.md` or `docs/solutions/**` files were present in this checkout, so repository code and checked-in docs remain the source of truth.

Sources: [README.md:119-139](), [docs/internal/skills-customization-ideas.md:1-14]()

## Scout Summary

| Candidate | Demo next | Copy elsewhere | Productize when |
| --- | --- | --- | --- |
| Composable terminal primitives | Multi-agent workspace with splits, notifications, CLI sends, and browser sidecar | Any developer tool that wants agent orchestration without owning the agent | Workflows can be saved, shared, and trusted per project |
| Source-portable hooks and skills | `cmux hooks setup` across Codex, Grok, Cursor, Gemini, OpenCode, and others | Adapter registry for any tool that emits lifecycle or permission events | Hook install, uninstall, validation, and restore become reliable user flows |
| Browser-plus-terminal automation | Agent inspects a dev server, clicks UI, reads console errors, then fixes code in terminal | Browser automation panel for repo-local QA and docs previews | Browser commands expose stable snapshots and deterministic post-action state |
| Provider-neutral remote compute | Create/attach/exec/destroy VM flows with provider selection | BYOC remote sandbox abstraction | Driver contract supports billing, credentials, revoke, snapshot, and browser proxy uniformly |
| Trust-gated project actions | `.cmux` or `cmux.json` action runs after explicit trust | Any repo-defined command palette or dock surface | Trust fingerprints, rollback, previews, and portable bundles are first-class |

Sources: [README.md:87-90](), [CLI/cmux.swift:4035-4459](), [web/services/vms/drivers/types.ts:1-104](), [Sources/CmuxConfigExecutor.swift:188-240]()

## 1. Demo Composable Terminal Primitives

The README’s strongest product claim is that cmux is “a primitive, not a solution”: terminal, browser, notifications, workspaces, splits, tabs, and CLI control are intentionally left composable rather than forced into one agent workflow. That maps directly to the code: the CLI can send text and keys to a selected workspace/surface, create notifications, manage sidebar status/progress/logs, run hooks, and dispatch browser commands through the same socket-facing command surface.

A good demo should avoid “one magic agent” framing. Show three small primitives combining:

1. Start two agent terminals in separate surfaces.
2. Use `cmux notify`, status, progress, or logs to mark which one needs review.
3. Open a browser split and let an agent inspect or act on a local dev server.
4. Jump between unread notifications and focused surfaces.

Sources: [README.md:125-129](), [CLI/cmux.swift:4041-4078](), [CLI/cmux.swift:4124-4193](), [CLI/cmux.swift:4295-4377]()

```text
Developer workflow
  ├─ terminal surfaces: agent CLIs, shell commands, tmux-compatible verbs
  ├─ browser surfaces: app preview, DOM snapshots, console/errors
  ├─ sidebar state: notifications, status, progress, logs
  └─ socket/CLI: shared automation layer for scripts and agents
```

The reusable product idea is a “developer workbench primitive layer”: other tools can copy the split between UI surfaces and socket commands without copying cmux’s macOS UI.

## 2. Copy the Source-Portable Hook Adapter Pattern

`AgentHookDef` is the clearest adapter shape in the repo. It models each agent by name, display name, config path, disable env var, hook marker, binary name, config format, native events, feed-hook events, aliases, and optional post-install behavior. The definitions cover multiple hook formats instead of assuming one vendor protocol.

The hook shell command is also source-portable: it prefers `CMUX_BUNDLED_CLI_PATH`, falls back to `command -v cmux`, respects `CMUX_SOCKET_PATH`, checks `CMUX_SURFACE_ID`, and emits `{}` when it cannot safely route the event. That is a productizable pattern for portable hook packs: a repo, file, or catalog source can install an adapter without binding the architecture to a model provider.

Sources: [CLI/CMUXCLI+AgentHookDefinitions.swift:6-47](), [CLI/CMUXCLI+AgentHookDefinitions.swift:122-245](), [CLI/CMUXCLI+AgentHookDefinitions.swift:299-320](), [CLI/CMUXCLI+AgentHookDefinitions.swift:479-520]()

### What to Productize

| Product surface | Why it is strong | Provider-neutral rule |
| --- | --- | --- |
| Hook adapter catalog | Agent integrations are data-shaped and already support multiple config formats | Catalog entries describe files, commands, events, and reply shapes, not model vendors |
| Hook health doctor | Installed hooks can drift; adapters need validation and repair | Validate local files and binaries only; do not require hosted accounts |
| Feed bridge SDK | Feed already normalizes permission, plan, and question events | Source may be file, repo, or catalog; event transport remains cmux socket JSON |

The Feed docs confirm the higher-level workflow: agents pipe events to `cmux hooks feed --source <agent>`, cmux forwards them as `feed.push`, and replies return through `feed.permission.reply`, `feed.question.reply`, or `feed.exit_plan.reply`. The important caveat is also documented: Feed is advisory and times out, so it should not be positioned as a hard workflow lock.

Sources: [docs/feed.md:13-50](), [docs/feed.md:63-99](), [docs/feed.md:101-134]()

## 3. Demo Browser-Plus-Terminal Automation as a Real QA Loop

The browser surface is more than “open a URL.” The v2 socket dispatch includes navigation, snapshots, JS evaluation, waits, clicks, typing, filling, screenshots, selectors, frames, dialogs, cookies, storage, tabs, console logs, errors, highlighting, state save/load, viewport/geolocation/offline controls, network routing, and screencast/input commands.

That makes the best demo a local QA loop:

1. Agent runs the app in a terminal.
2. Agent opens a browser split.
3. Agent snapshots the page, clicks or fills a form, reads console/errors, and takes a screenshot.
4. Agent returns to the terminal to patch the bug.

Sources: [README.md:51-53](), [README.md:127-129](), [Sources/TerminalController.swift:3521-3689](), [docs/agent-browser-port-spec.md:8-22]()

```swift
// Sources/TerminalController.swift
case "browser.snapshot":
    return v2Result(id: id, self.v2BrowserSnapshot(params: params))
case "browser.eval":
    return v2Result(id: id, self.v2BrowserEval(params: params))
case "browser.click":
    return v2Result(id: id, self.v2BrowserClick(params: params))
case "browser.fill":
    return v2Result(id: id, self.v2BrowserFill(params: params))
```

The copyable pattern is “browser as an adjacent programmable surface,” not a separate browser-testing service. For a Grok-Wiki integration, keep this provider-neutral by generating browser workflows from repository files or reusable catalog recipes, then executing through the local socket API. The recipe source can be a checked-in file, a repository skill, or a catalog package; the browser runtime should not assume a specific LLM provider.

## 4. Productize Provider-Neutral Remote Compute

The VM driver contract is already intentionally narrow and provider-neutral. `ProviderId` currently includes `e2b` and `freestyle`, but callers hold a `VMProvider` interface with create/destroy/status/pause/resume/exec/snapshot/restore/openAttach/openSSH/revoke methods. Attach endpoints are typed as either SSH or WebSocket PTY, and SSH credentials include revocation handles for providers that mint revocable identities.

The gateway wraps provider calls in Effect and converts provider failures into typed `VmProviderOperationError`s. Provider selection is registry-based, with `CMUX_VM_DEFAULT_PROVIDER` choosing the default when set.

Sources: [web/services/vms/drivers/types.ts:1-36](), [web/services/vms/drivers/types.ts:54-104](), [web/services/vms/drivers/index.ts:8-30](), [web/services/vms/providerGateway.ts:17-76]()

```mermaid
flowchart LR
  subgraph CLI_and_App["CLI / app socket"]
    VMCLI["cmux vm / cloud commands"]
  end

  subgraph WebServices["web/services/vms"]
    Gateway["VmProviderGateway"]
    Registry["drivers/index.ts registry"]
    Contract["VMProvider interface"]
  end

  subgraph Providers["Provider drivers"]
    E2B["E2BProvider"]
    Freestyle["FreestyleProvider"]
  end

  VMCLI --> Gateway
  Gateway --> Registry
  Registry --> Contract
  Contract --> E2B
  Contract --> Freestyle
```

This is the most obvious BYOC/BYOK-compatible product line: let users bring a provider, image, key, or remote workspace policy while cmux keeps a stable attach and automation contract. Productize the driver interface before adding provider-specific UI flourishes.

## 5. Turn Trust-Gated Project Actions Into Shareable Workflow Bundles

Project-local actions are powerful because they can define terminal commands, agent launches, workspace commands, icons, shortcuts, command-palette metadata, confirmation behavior, and surface tab bar buttons. The parser validates action types and prevents ambiguous button definitions, while the executor checks project-local commands against a trust descriptor before running.

The trust model is fingerprint-based. A descriptor includes schema version, action ID, kind, command or workspace command, config path, project root, and icon fingerprint; trusted fingerprints are stored in Application Support. Project actions from the global config run directly, while project-local actions prompt unless already trusted or explicitly confirmed.

Sources: [Sources/CmuxConfig.swift:10-21](), [Sources/CmuxConfig.swift:783-908](), [Sources/CmuxConfig.swift:1030-1095](), [Sources/CmuxConfig.swift:1234-1336](), [Sources/CmuxActionTrust.swift:4-24](), [Sources/CmuxActionTrust.swift:27-76](), [Sources/CmuxConfigExecutor.swift:188-240]()

### What to Demo

| Workflow | Code-backed capability | Product risk to solve |
| --- | --- | --- |
| Repo command palette | `actions` include title, subtitle, keywords, shortcut, icon, tooltip, confirm, and target | Users need preview/diff before trusting generated config |
| Project tab buttons | `surfaceTabBarButtons` can reference built-ins, commands, agents, or workspace commands | Buttons must stay readable and safe when inherited from a repo |
| Team workflow bundle | Internal planning notes already list `.cmux` bundles, Dock controls, hooks, and browser previews as candidate examples | Need import/export/reset and one-command rollback |

Sources: [docs/internal/skills-customization-ideas.md:15-28](), [docs/internal/skills-customization-ideas.md:45-74](), [Sources/CmuxConfigExecutor.swift:275-325]()

A Grok-Wiki integration should treat generated workflow bundles as portable source artifacts. The wiki can propose `.cmux/` examples or catalog skills, but execution must flow through cmux validation and trust prompts. That keeps the design independent of any model provider and makes BYOK/BYOC possible: users can generate bundles with one tool, review them as files, and run them locally through trusted cmux actions.

## 6. Keep the Page Shape Honest

The strongest reusable ideas are source-grounded, but not equally mature:

| Idea | Confidence | Why |
| --- | --- | --- |
| Terminal/browser/socket primitives | High | README, CLI routing, and `TerminalController` all expose broad scriptable surfaces |
| Agent hook adapters | High | `AgentHookDef` centralizes real integrations across many agents |
| Feed as decision surface | Medium-high | Docs describe working event/reply path and timeout semantics; Codex plan questions have a documented limitation |
| Remote compute abstraction | Medium | Driver contract is clean, but product readiness depends on provider rollout and image behavior |
| Shareable project workflow bundles | Medium | Config/trust primitives exist; examples and lifecycle tooling are still product candidates |

Sources: [docs/feed.md:124-134](), [web/services/vms/drivers/types.ts:76-104](), [docs/internal/skills-customization-ideas.md:45-74]()

## Closing Summary

The next product bets should preserve cmux’s core advantage: local, scriptable, provider-neutral primitives that users can compose around their own agents, repos, keys, and compute. Demo the primitives together, copy the adapter boundaries, and productize only where trust, portability, and rollback are strong enough for project-local automation. The code already supports that direction through the socket/CLI surface, multi-agent hook definitions, browser automation verbs, VM provider interface, and fingerprinted project-action trust path. Sources: [README.md:133-139](), [CLI/CMUXCLI+AgentHookDefinitions.swift:6-47](), [Sources/TerminalController.swift:3521-3689](), [web/services/vms/providerGateway.ts:44-76](), [Sources/CmuxConfigExecutor.swift:313-373]()