# Settings (/web/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 [#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](/web/spaces), [Assignments](/web/assignments), [Triggers](/web/triggers), or [Automations](/web/automations) instead. ## Set these up first [#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 [#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](/web/models). For the connection-specific operating guide, see [Connections and MCP](/configure-and-extend/connections-and-mcp). ## Start at the top of the page first [#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 [#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](/web/spaces) but still cannot participate in [Triggers](/web/triggers) or automation, the usual cause is missing App coverage for that owner. ## Billing and Access [#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](/plans-and-billing) for the stable billing entry point. ## GitHub App coverage details [#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] Connections are where you register the non-model systems agents can call. Connections is about **inbound** integrations — Mogplex calling external systems. For the opposite direction — external agents calling into Mogplex — see [Extend](/extend): Skills today, the [MCP server](/extend/mcp-server) in preview. 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](/configure-and-extend/connections-and-mcp) and [Connection Scope and Overrides](/web/guides/connection-scope-and-overrides). ### Current MCP quick-add presets [#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 [#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](/integrations/slack). ## Access Tokens [#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 [#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](/web/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 [#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 [#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.