Settings

Settings is the account-level control plane for Mogplex.

If something about your identity, repo coverage, model access, shared tools, or CLI sync looks wrong, this is the first page to inspect.

Use this page to fix account problems, not routing logic

Settings is where you answer questions like:

• can Mogplex actually act on behalf of this GitHub user or org?
• does the account plan include hosted model and sandbox access?
• are the shared MCP or REST connections healthy?
• why did the CLI sign in, but not inherit the hosted state I expected?

If the question is “what should run for this repo?”, use Projects, Assignments, Triggers, or Automations instead.

Set these up first

For a new account, the most reliable order is:

1. connect GitHub
2. install the Mogplex GitHub App for the personal account or orgs that own the repos you want to use
3. confirm the account plan includes the model and sandbox access you need
4. add shared connections or MCP servers after the account basics are working
5. generate CLI or API access tokens only when the CLI or scripts need to authenticate as Mogplex itself

That order keeps you from debugging downstream surfaces before the account can actually support them.

What lives here

Settings currently groups together:

• Account state for GitHub identity, GitHub App coverage, and account readiness
• Connections for REST APIs and MCP servers your agents can use
• Slack for workspace install, channel-to-repo links, and repo-agent controls
• Access Tokens for CLI, API, and script authentication
• Preferences for theme and default model
• Models for the hosted model catalog your account can actually use

For the model-specific operating guide, see Available Models.

For the connection-specific operating guide, see Connections and MCP.

Start at the top of the page first

The top of Settings is intentionally opinionated.

It is the part of the product that tells you:

• whether GitHub is connected at all
• whether the GitHub App is installed on the right owner
• whether synced repos exist yet
• whether billing, model access, or sandbox access still needs action
• what the next most likely setup step is

Treat that top block as the “what is missing?” answer before you debug any deeper form.

Account section

The top of Settings is intentionally operational, not decorative.

It shows:

• current GitHub connection mode and status
• GitHub App coverage and synced repo counts
• the next recommended setup step, such as connecting GitHub, finishing App install, or syncing repos into Projects
• account access state for hosted model and sandbox work

Two distinctions matter here:

• GitHub OAuth is about account identity and repo discovery
• GitHub App coverage is what makes repos triggerable for reviews, automations, and webhook-backed routing

If a repo shows up in Projects but still cannot participate in Triggers or automation, the usual cause is missing App coverage for that owner.

Billing and Access

Hosted model calls and sandbox usage are billed through Mogplex.

Users do not need external model credentials or external sandbox accounts for normal hosted work. If a model picker is empty or a sandbox cannot launch because access is missing, check the account plan or entitlement state before editing agents, prompts, or repo launch settings.

See Plans & Billing for the stable billing entry point.

GitHub App coverage details

The GitHub App coverage block shows more than a binary yes/no.

For each installation, Mogplex can show:

• the account or org name
• the installation scope
• how many repos Mogplex has associated with that installation
• a GitHub manage link when one can be derived
• the list of synced repos under that installation

This is the fastest way to answer a common setup problem:

Can Mogplex merely see this repo, or is it actually covered for App-backed work?

Connections

Connections are where you register the non-model systems agents can call.

Mogplex supports two connection categories:

• REST API connections
• MCP Server connections

The page supports:

• quick-add MCP presets
• fully custom REST or MCP endpoints
• auth modes including none, bearer token, API key, basic auth, and OAuth
• testing a connection after setup
• enable, disable, reconnect, or remove actions

The operational rule here is simple:

configure and test the integration in Settings first, then debug agent prompts or routing only after the connection itself is known-good.

Settings is also only part of the story.

When you are inside an active repo workspace, Mogplex can resolve connections with repo context:

• Global connections stay available everywhere by default
• This Project connections only exist for one repo
• one repo can explicitly exclude a global connection without deleting it account-wide

Use Settings to onboard and validate the integration itself. Use the repo context when one codebase needs a different tool surface. For the full configuration model, see Connections and MCP and Connection Scope and Overrides.

Current MCP quick-add presets

The built-in MCP presets currently include:

• Zapier
• Notion
• Supabase
• Browserbase
• Sentry
• Sanity CMS
• Linear

Some presets use direct credentials, while others use an OAuth flow. Settings surfaces the connection health state and last-tested metadata so you can fix the integration before debugging agent prompts.

Slack

The Slack section installs the Mogplex Slack app and manages workspace-level Slack behavior.

Use it to:

• install or disconnect Slack workspaces
• link Slack channels to Mogplex repos
• enable or disable Slack-started repo-agent runs
• restrict repo-agent runs to specific Slack user IDs
• set a monthly Slack repo-agent run limit

Linked channels change @mogplex behavior. In an unlinked channel, Mogplex can reply conversationally. In a linked channel, a real instruction after @mogplex starts a repo-agent run against the linked repo.

For the full Slack model, see Slack.

Access Tokens

Access tokens are for authenticating Mogplex clients and scripts. They are not model-provider credentials.

Use them when the CLI or another Mogplex-aware script needs to authenticate as you against Mogplex itself.

The section supports:

• naming each token
• optional expiration windows
• one-time token display at creation
• copy-on-create flow
• last-used metadata
• revocation

Hosted model and sandbox access comes from the account plan, not from user-supplied provider or sandbox credentials.

Preferences and Models

Settings also owns the user-level defaults that affect hosted behavior and sync surfaces.

The important split is:

• Models section controls what models are available to the account
• Agent settings choose which available model a specific agent should use

If an agent cannot select the model you expect, check Models before you edit the agent itself.

Use Available Models when you need the fuller model-access mental model: enabled state, defaults, plan access, CLI sync, hidden legacy models, and repo-level exclusions.

Fast troubleshooting map

• Triggers page is empty: GitHub OAuth may be connected, but App coverage is missing for the repo owner.
• The CLI signs in but no shared models or MCP entries appear: the Mogplex account exists, but the hosted account may still lack model access or shared connection setup.
• A connection exists but agent calls still fail: test the connection here before debugging prompts or routing.
• Slack replies but does not start repo work: check channel-to-repo links, repo-agent enabled state, Slack user mapping, and monthly/user limits in the Slack section.
• Sandbox launch says access is unavailable: check the account plan and entitlement state before changing repo settings.
• The repo is visible, but webhook-backed work still does not fire: visibility and App-backed coverage are different states. Check the installation list here first.

Why Settings matters

The web app and CLI share parts of this control plane.

The cleanest Mogplex setup is to wire shared account state here once, then let the CLI reuse that state for synced models, shared MCP configuration, and account-backed login.