Overview

The web app is the shared source of truth for Mogplex account state, GitHub coverage, reusable agents, hosted routing, and runtime inspection.

If the question is about account setup, GitHub eligibility, reusable hosted behavior, or why something ran the way it did, the answer usually starts here.

What the web app actually owns

• Projects lives at /spaces. It is where repository import, project organization, sandbox launch, and workspace opening happen.
• Sandboxes lives at /spaces/sandboxes. It is the cross-repo runtime view for running, pending, and stale preview environments.
• Agents lives under /agents/* and manages the reusable agent roster plus shared skills, rules, and context.
• Automations at /automations is the canvas builder for multi-step GitHub-triggered workflows.
• Triggers at /triggers is the lighter-weight event-to-agent router for direct GitHub webhook handling.
• Assignments at /assignments binds repos to agents for repeatable review, cron, and triage work.
• Observability tracks runs, pressure, failures, model calls, tool usage, and sandbox-linked activity.
• Settings manages GitHub identity, App coverage, connections, access tokens, models, preferences, billing access, and synced MCP definitions.
• Available Models explains the live model catalog, enabled-state rules, default-model behavior, plan access, CLI sync, and repo-level exclusions.

The clean mental model

The web app is not just “the browser version of the CLI.”

It owns three different jobs:

• setup: identity, GitHub coverage, connections, models, and repo sync
• routing: deciding what should run from GitHub events, repo-owned rules, or workflow graphs
• inspection: checking runs, failures, tool calls, cost, and sandbox health

That framing helps you choose the right page faster:

• use Settings and Installations when Mogplex cannot yet do the work
• use Available Models when a picker, agent, flow, or CLI run cannot use the model you expect
• use Projects, Triggers, Assignments, or Automations when you are deciding what should run
• use Observability and Sandboxes after work has queued or started

Start in this order

For a new account or a new repo, the most reliable path through the product is:

1. Settings to connect GitHub and confirm your account can use the product.
2. Installations to verify GitHub App coverage for the correct user or org.
3. Projects to sync repos, organize them, and open a workspace.
4. Agents to create or fork the agents you actually want to run.
5. Triggers, Assignments, or Automations depending on how much routing logic you need.

That sequence matters because most apparent “routing bugs” are really setup bugs: missing App coverage, missing repo sync, or missing shared account state.

Choose the smallest routing surface that fits the job

• Use Triggers when the rule is simply one GitHub event -> one agent.
• Use Assignments when the repo is the durable unit of routing and you want standing work such as PR review, issue triage, CI failure response, or cron.
• Use Automations when you need multiple steps, branching, delays, publishable drafts, or explicit mention-entry workflows.

If the choice is not obvious yet, read Choose the Right Routing Surface.

Web app vs CLI

The clean split is usually:

• do shared account setup, GitHub coverage, and routing in the web app
• do repo-local execution in the CLI
• come back to the web app for observability, repair actions, and shared hosted state

This matters because Mogplex intentionally reuses some hosted state in the CLI, including account-backed model defaults and remote MCP definitions.

What a healthy setup feels like

Once the web app side is set up correctly:

• the correct repos appear in Projects
• the correct owner shows real GitHub App coverage in Installations
• the agents you expect are available for routing
• Triggers or Automations offer real installations instead of looking empty
• Observability can tell you what actually ran

Legacy route notes

Several older dashboard routes still exist, but they now forward to the current surfaces:

• /flows redirects to /automations
• /library redirects to agent libraries or model settings, depending on tab
• /primitives redirects to the agent library surfaces

The product language still says Projects even though the route is /spaces. The docs use the current UI label and call out the route where it matters.

For the full redirect map, use Legacy Routes.

Common “where do I fix this?” questions

• Why is Triggers empty? Usually because GitHub OAuth is connected but the Mogplex GitHub App is not installed for the owner that holds the repo. Check Installations.
• Why can I see repos but not launch the kind of work I want? Repo sync and webhook coverage are separate concerns. Projects can show synced repos before they are fully triggerable.
• Where do I set up models and external tools? Use Settings for account access and connections, and Available Models for model availability, defaults, and enabled state. Agent behavior belongs in Agents.
• Where do I manually stop or inspect previews across repos? Use Sandboxes.
• Where do I start for mention-driven workflows? Use Triggers for a direct mention route, or Automations if the mention should fan into a workflow.