Skip to content

Configuration

Each agent uses your own configuration: your settings, MCP servers, skills, plugins, hooks, subagents, custom commands and instruction files. Moontors never writes your configuration files. Installing and removing things stays in the agent’s own terminal.

What Moontors can do is switch things on and off for its own sessions. It keeps those choices in its own store and applies them each time the agent starts, so your own files stay as they are. A choice that matches your own setting is dropped, so a later change in your own configuration shows through. What your organization manages is shown, but locked.

The Configuration button at the window’s right edge opens it on Status, with three tabs:

  • Status: see Insight and code workflows.
  • This session: the folders the session can work in, and the rules you allowed for this session.
  • The agent’s own tab, named after it: its MCP servers, skills, plugins, hooks, subagents and instruction files. Changes here apply to every session of that agent.

The dialog belongs to the session it opened on, so it closes when you open another session. While the agent is signed out, its tab can’t be read, and the dialog offers Sign in.

A change applies at once where the agent allows it. Otherwise the agent takes it when it next starts, which is from the session’s next turn, and the dialog says so. While something still needs the agent that’s running, such as the session’s background tasks or an MCP server’s sign-in, the change waits until that work ends. With background tasks running, the dialog says “In this session, the change applies once its background tasks end.” At the start of your next turn, the transcript says it once: “This change applies once the session’s background work ends, since it keeps the current agent running.” That goes for the agent’s tab, the rules and folders on This session, /add-dir, fast mode, the output style and auto-compact.

MCP servers, skills, plugins, hooks and instruction files each show where they come from: user, project, local, account, plugin or managed. account is what your account brings: with Claude Code, the skills and plugins it syncs from your claude.ai account, and claude.ai’s connectors; with Codex, the plugins and apps of your ChatGPT account. A switch that can’t be used is dimmed, and its tooltip says why.

Each command below opens its own tab and section.

Claude CodeCodexGemini CLI
/mcp: list and switch MCP serversyes, at onceyesyes
Reconnect an MCP servereach serverall at once—
Sign in to an MCP server—yes, or /mcp login <server>—
/skills, /plugins, /hooksyesyesyes
A plugin’s every partyesyesyes, as an extension
Switch every hook at onceyes——
/agents: list subagentsyes—yes
/memory: instruction filesyesyesyes
The agent’s own listssandboxmemories, experimental features, appstools, custom commands, policies, settings
Reloadyes——
Background tasksyesyes—
/add-dir: more foldersyesyesyes
Allow for this sessionyesyesyes
/logoutyesyesyes

Claude Code’s claude.ai connectors connect on claude.ai instead, through Authorize (see /mcp).

Lists each MCP server with its state, its tools, and switches to turn it on or off. The state is starting, connected, needs sign-in, failed, off or configured, and a failed server shows its error. Gemini CLI doesn’t report a server’s state, so its servers show as configured. In a folder Gemini CLI doesn’t trust, it starts none of them, so their switches are off and locked.

A Gemini CLI server that asks to sign in can’t do it in Moontors. Moontors turns that server off for the run and starts the session again without it, once, and the transcript says “The MCP server <name> asked to sign in, which the agent can’t do here, so it goes on without it.” Asked in the middle of a turn, the turn ends there. Asked again once it’s off, the agent stops.

In Codex, a server that needs sign-in shows Sign in, which opens its sign-in page in your browser. /mcp login <server> in the composer opens /mcp and starts the sign-in of the server it names.

A Codex plugin’s MCP servers are listed from plugin, with no switch of their own: the plugin’s switch in /plugins turns them off with the rest of it.

When Codex asks before an MCP server’s tool runs, the question shows like any other, with Allow for this session where it applies: not for the tools of a plugin’s MCP servers, or of Codex’s apps.

With a claude.ai sign-in, Claude Code lists your claude.ai account’s connectors among its MCP servers, from account, each with its switch. A connector you haven’t authorized yet shows Authorize, which opens claude.ai’s connectors page in your browser: authorize it there, and it connects from the agent’s next start. An API key or an Anthropic Console sign-in brings no connectors.

Lists, with a switch on each skill and plugin. With Gemini CLI, /plugins lists its extensions. Subagents are a list only. With Claude Code, a skill and a command that share a name can’t be switched, since one switch would change both.

Hooks switch differently in each agent:

  • Claude Code: all at once only, with All hooks, which covers the plugins’ hooks too. Each hook is listed, but its own switch is locked.
  • Codex: each hook shows whether Codex trusts it: Trusted, Not trusted, Changed since trusted or Managed. Until the session runs, it says “Its trust shows once the session runs”. A hook Codex doesn’t trust stays off and can’t be switched here, as Moontors doesn’t grant trust. A plugin’s hooks keep the trust your own Codex gave them.
  • Gemini CLI: each hook has its own switch. In a folder Gemini CLI doesn’t trust, the hooks in your settings files don’t run, and aren’t listed.

With Claude Code, where your organization’s managed settings turn every hook off, All hooks is locked and says so.

A plugin brings its parts with it, and each agent takes them its own way. With Gemini CLI, a plugin is an extension.

Claude CodeCodexGemini CLI
Skills and commandsyesyesyes
MCP serversyesyesyes
Hooksyesyes, once Codex trusts themyes
Subagentsyes—yes
Apps—yes, with a ChatGPT sign-in—
Policies——yes

Each part shows in its own list, marked plugin. A plugin’s switch, in /plugins, turns all of its parts on or off together. A part’s own switch, where its list has one, still applies.

Claude Code gets each plugin whole:

  • The options you set for a plugin in your own Claude Code settings reach it, with your organization’s over them.
  • A plugin’s sensitive options, and its MCP servers’ secrets, are in your own Claude Code’s entry in the system keychain, beside its sign-in; on Windows and Linux, in its credentials file. Moontors reads them only when it starts a session with a plugin that declares one. On macOS the system doesn’t ask you first, as Moontors reads the entry with the same system tool Claude Code itself uses for it. Of that entry, Moontors keeps only the secrets of the plugins it gives the session, never your sign-in, and hands them to the session’s Claude Code in a private file that goes when that run of the agent ends, never logging them or passing them on. It never changes your entry.
  • Two plugins with the same name get neither’s options or secrets, as Claude Code can’t tell them apart.
  • The plugins your claude.ai account syncs show from account, on or off as your own Claude Code settings have them until you switch one in Moontors. One your organization’s settings turn on or off can’t be switched.

Codex gets your plugins as your own Codex has them installed: Moontors copies Codex’s plugin cache into its own Codex home at each launch, so a plugin’s skills, commands, MCP servers, hooks and apps reach it. A plugin you install in your own Codex arrives from the agent’s next start.

  • The plugins of your ChatGPT account show from account, once a session has listed them. Your account keeps its own on and off for them, which Moontors never writes to, so their switch turns off each of their parts instead.
  • A plugin’s hooks keep the trust your own Codex gave them.

Gemini CLI gets each extension whole, linked from your own. Its parts show across the lists, and its policies in /policies.

What a plugin saves for itself starts fresh in Moontors (see Known limits).

The instruction files the agent reads, such as CLAUDE.md, AGENTS.md and GEMINI.md. Open one in your text editor, then choose Read them again so the agent picks up your changes. Files that aren’t Markdown or plain text are shown in their folder instead.

Each agent has a few lists of its own, after the ones above. Each has its own command, which opens it:

  • Claude Code: /sandbox, its sandbox, with three switches: Sandbox Bash commands, Allow sandboxed commands without asking and Allow commands outside the sandbox. Commands left outside the sandbox, where your settings name any, are shown as they are.
  • Codex:
    • /memories: whether Codex uses and makes memories, each with a switch.
    • /experimental: Codex’s experimental features in beta, each with a switch, listed while the agent runs. A feature whose name Codex’s configuration can’t hold has no switch.
    • /apps: the apps of your ChatGPT account and of your plugins, each from account with its switch. An app a plugin brings names that plugin, and switching the plugin off turns its apps off too. One you haven’t connected shows Not connected, with Authorize, which opens the app’s page in your browser to connect it. Apps come with a ChatGPT sign-in: with an API key, the list says so instead. Before any session has run, it says “Apps show once a session runs.” Like its command, /apps is untested: no account Moontors records with has apps.
  • Gemini CLI:
    • /tools: its tools, each with a switch.
    • /commands: your custom commands.
    • /policies: the policy files Gemini CLI reads, read only: your organization’s, yours or those your policyPaths setting names, the trusted folder’s, and each active extension’s, without the allow and yolo rules Gemini CLI drops from an extension’s.
    • /settings: your settings, read only, each from the last layer that sets it. MCP servers, skills, hooks and the sign-in show in their own places instead.

Like every other switch here, these apply to every session of the agent, from its next start.

With Claude Code, Reload, at the top of its tab, reads its setup again and has the running agent reload its skills and plugins, as Claude Code’s /reload-skills and /reload-plugins do. Those commands do the same in Moontors, and so does /reload.

With Claude Code, three of its own settings sit beside the model in the composer’s toolbar. When the toolbar is too narrow for them, they fold into one Settings menu. Each is kept with the session, like the model, and applies from the agent’s next start. Each starts at Your setting, which leaves your own Claude Code setting in effect.

  • Fast mode (/fast): on or off. Only some models have it, and only some accounts can use it; Claude Code says so when yours can’t. While it’s on, switching to a model without it is refused.
  • Output style (/output-style): how the agent words its answers. Claude Code’s own styles are listed, and yours from your output-styles folders.
  • When it compacts (/autocompact): on its own, never, or past 100K, 200K, 500K or 1M tokens. Once the agent has reported the model’s context, only the numbers below it are offered. A number the model’s context can’t hold, as after switching to a smaller model, is dropped once the agent next reports its context, and your own setting applies again. The transcript says so.

The commands open their menus.

With Codex, Daybreak (/daybreak) sits there too, once your own Codex turns on its cli_daybreak feature: on or off, starting at Your setting. Daybreak sends security work to Codex’s cyber access programs. Only models Codex confirms for your account take it, and while it’s on, switching to another model is refused. It needs an eligible ChatGPT account, or an API key with Daybreak support. The / list and /help mark it Untested, as no account Moontors records with has it.

Claude Code and Codex can run tasks in the background, such as a dev server. A row above the message box lists them, each with Output, which shows what it has printed so far, and Stop. The card shows how many run, and /tasks goes to that row. They keep running when the session is idle. While any run, /clear, /rewind and /cd are refused, with a message to stop them first. Archiving the session or signing out stops them, and the confirmation names them.

Lets the agent work in another folder too. /add-dir <folder> adds the folder at once: a relative path is taken from the session’s folder, and ~ is your home folder. /add-dir alone opens the folders under This session, where Add folder… picks one and Remove takes one away. Not while a turn is running.

The folder must exist. It can’t be your home folder itself, or inside the session’s folder or a folder already added. For a worktree session it also can’t be your main checkout, a folder inside it, or a folder that holds it, since that would undo the worktree’s separation. Gemini CLI can’t add a folder whose path has a comma, or a space at its start or end, as it would split or trim the path. An added folder that’s gone when the agent starts is left out, and the transcript says so. /diff and @ stay on the session’s own folder.

When the agent asks before a tool, Allow for this session allows that exact request for the rest of the session, and forks of it. The rules are listed under This session, beside the agent’s own rules from your settings, which are read-only. A rule you remove stops applying at once in Moontors, and in the agent from its next start.

Opens the sign-in dialog to sign out. Accounts offers the same sign-out. See Signing in.