Settings

Open Settings in the sidebar to manage your account or team.

Settings opens a secondary sidebar. Select a section to open its page. Use the back arrow beside Settings to return to the main navigation. On mobile, open the navigation menu to select a Settings page.

Settings pagesCopy Anchor Link

Each section has its own URL. Reloads and bookmarks open the same section.

Team Settings includes Members, Provider Keys, Models, and Billing. Owners and admins also see Audit. Each uses the same route pattern, such as /<team>/settings/models. Personal keys and account preferences stay in the personal scope.

Each old tab link opens its section's page. For example, ?tab=keys&sub=cli opens Mogplex Keys.

BillingCopy Anchor Link

Open Settings → Billing for two tabs:

• Billing Settings: manage the plan, payment method, invoices, inference credit, and available add-ons.
• Usage: view the inference balance and recent usage costs.

The Usage tab uses /<scope>/settings/billing?tab=usage. Reloads and browser Back preserve the selected tab. Team billing uses the current team and its permissions.

Account setup and workflow setupCopy Anchor Link

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?
• 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 firstCopy Anchor Link

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 hereCopy Anchor Link

• Account shows GitHub identity, App coverage, account access, and Run checks.
• Teams lists team memberships and controls.
• Provider Keys stores keys for model providers.
• Mogplex Keys manages tokens for CLI, API, and script access.
• Billing contains Billing Settings and Usage.

Models and Connections have their own sidebar destinations. Open Connections → MCP Servers to manage saved servers for web chat and the CLI. Use Test connection to check a saved HTTP server and list its tools without running them. Edit Tool permissions to set approval, allowlists, blocklists, and per-tool overrides. In hosted chat, tools that require approval run only in Control. The CLI uses its own prompts. For model setup, see Available Models.

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

Account sectionCopy Anchor Link

The Account page 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.

Run checksCopy Anchor Link

While an agent works, a small evaluation model judges what it is doing:

• whether a shell command would destroy something remote, such as a force push or a dropped database
• whether a command that reported success actually failed
• whether the agent's final claims, such as "tests pass" or "PR opened", match what its tools did
• which of the memories loaded for a request, and which of the skills available to it, the request actually needed. Skills here means the ones attached to the agent and the ones in your own library. This is recorded only and does not change what is loaded.

The same model answers Classify nodes in Automations.

Run checks turns all of that on or off with one switch. It is on by default.

Work inside a team always follows the team's setting, never a member's own. Every change to a team's setting is written to the team audit log.

When it is on, short excerpts of commands, tool output, and the agent's final message are sent to the evaluation model with secrets removed. So is your request, together with the memories loaded for it and summaries of the skills available to it.

When it is off:

• nothing is sent, and nothing about those judgments is stored
• a destructive command no longer pauses for approval through this check; your other approval rules and the shell guard still apply
• a Classify node fails with a message that names this setting, so wire its error path if the flow must keep going

A change can take up to 30 seconds to reach runs that are already in progress.

Billing and AccessCopy Anchor Link

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.

The Billing Settings tab shows the monthly plan cost, next due date, protected card summary, and recent invoices. It also lets an authorized owner or admin update the payment method, open the complete invoice history, buy inference credit, and manage available capacity add-ons.

The plan's parallel-run value is a static entitlement, not a live usage meter. Use the active-run surfaces to see current work. New work waits when all run slots are in use.

See Plans & Billing for current prices, credit rules, capacity definitions, invoices, payment methods, and billing support.

GitHub App coverage detailsCopy Anchor Link

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?

ConnectionsCopy Anchor Link

Open Connections from the app sidebar to add or manage external services. This page now lives at /<scope>/connections, outside Settings. Use Integrations for services and MCP Servers for saved servers in web chat and the CLI. The MCP Servers tab has a direct link at /<scope>/connections?tab=mcp. Old Settings links still redirect to it.

Mogplex supports two connection categories:

• REST API connections
• MCP Server connections

The Integrations tab 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 Connections first, then debug agent prompts or routing only after the connection itself is known-good.

The account-level Connections page is 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 Connections to add and test 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 presetsCopy Anchor Link

The built-in MCP presets currently include:

• Zapier
• Notion
• Supabase
• Neon
• Browserbase
• Sentry
• Sanity CMS
• Linear
• Trigger.dev

Some presets use direct credentials, while others use an OAuth flow. Trigger.dev gives agents API tools that need no sandbox and also runs its MCP server inside sandboxes and the CLI; see How the Trigger preset works. Connections surfaces the connection health state and last-tested metadata so you can fix the integration before debugging agent prompts.

SlackCopy Anchor Link

Open Connections from the sidebar, then find the Slack section. It 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.

Provider KeysCopy Anchor Link

Open Settings → Provider Keys to add or remove your own model-provider credentials. This page supports AI Gateway, Anthropic, OpenAI, and OpenRouter. Personal keys belong to your account. Team keys use the selected team's permissions.

Team key accessCopy Anchor Link

Team Settings → Provider Keys also has a Mogplex API keys setting for the team's repositories:

• Each key's own access: a member's key can do what its owner allows. This is the default.
• Automations only: every member's key is held to the automations-only rule on the team's repositories, whatever the key itself allows.

Only a team owner can change it. Admins and other members see it read-only. Every change is written to the team audit log.

Mogplex KeysCopy Anchor Link

Open Settings → Mogplex Keys to manage access tokens for Mogplex clients and scripts. These tokens authenticate with Mogplex itself.

The page supports:

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

Key accessCopy Anchor Link

Every key has one of two access levels. You choose it when you create the key, it is shown on the key, and Limit to automations or Allow full access changes it later. A change applies to the key's next request.

An automations-only key gets 403 AUTOMATION_REQUIRED before anything is created when it tries to start runs or sandboxes, rerun a PR review, create, edit, publish, or delete automations, change a model override or repository environment variables, use hosted CLI inference, or change settings and saved MCP servers. MCP tools follow the same rules because they call the API with the key.

Use Automations only for a key held by another system, such as a build service that should start one named automation and nothing else. Keep Full access for CI jobs and scripts that start runs directly.

Signing in to Mogplex, and the CLI and MCP clients signed in with OAuth, do not use these keys and are not affected.

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

Preferences and ModelsCopy Anchor Link

Open the user menu to change the theme. Open Models in the main sidebar to manage model access. Use Models → Configuration to set the primary model and fallbacks.

The important split is:

• Models page 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 mapCopy Anchor Link

• 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 in Connections 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 of Connections.
• 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 mattersCopy Anchor Link

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.