Configure Plugin Settings

Many plugins expose a configuration form in Settings > Plugins > Configure. RealTimeX renders these forms from the plugin's own settings schema, so the exact fields can vary from plugin to plugin.

What the configuration modal is for

Plugin configuration is where you provide the values the plugin needs in order to work.

Common examples include:

• API keys
• provider base URLs
• default model names
• behavior presets
• risk or approval policies
• plugin-specific tags or lists
• file or directory paths produced by plugin editors

The current plugin config UI can also organize fields into grouped sections or tabs when the plugin schema requests it.

Common field types

RealTimeX plugin configuration supports several field styles.

Text fields

Used for values such as:

• API base URLs
• model names
• short labels or identifiers

Password fields

Used for secrets such as API keys.

These are usually required before the plugin can function.

Boolean toggles

Used for on/off behavior, for example:

• enable logging
• enable analysis
• allow fallback behavior

Select fields

Used when the plugin wants you to choose one value from a fixed list, such as:

• an approval preset
• a mode
• a predefined behavior profile

Multi-select fields

Used when the plugin can accept several allowed values at once, such as:

• approved tool kinds
• approved command groups

Tag-list fields

Used for free-form lists such as:

• extra command prefixes
• blocked prefixes
• custom patterns

LLM slots

Some plugins expose one or more LLM slots instead of plain text fields.

An LLM slot lets the plugin use a specific provider and model for one internal task. For example, a plugin might need a separate model for risk analysis or another background decision step.

Editor-backed fields

Some plugins expose richer configuration fields than a simple text box.

The current UI can include:

• Edit for a structured or file-backed editor flow
• AI Edit for a terminal-backed or agent-assisted editing flow

Use these when the plugin needs more than one raw string value, for example:

• generating a config file
• editing a prompt or template file
• applying a selected file path back into plugin settings

In those flows, saving the editor content and applying the editor result can be separate steps.

Grouped layouts

Plugin configuration is not always one long flat form.

Current builds can render grouped layouts such as:

• stacked sections
• tabbed configuration groups
• dedicated LLM configuration groups

This is normal when a plugin exposes many related settings or mixes normal fields with one or more LLM slots.

Save vs reload

Saving plugin settings stores the new values, but some plugins work more reliably after a manual reload.

A safe rule is:

• Save after changing configuration
• Reload the plugin afterward if the plugin powers a runtime feature or provider

If the plugin uses an editor-backed field, also make sure you applied the editor result back into the config before closing the modal.

When Configure does not appear

If a plugin card has no Configure button, that usually means one of the following:

• the plugin has no user-configurable settings
• the plugin only contributes built-in skills or background capability
• the plugin is already usable without setup

Best practices

• Add required secrets first, before enabling a provider-dependent plugin for users.
• Keep custom URLs and model names consistent with the service you are using.
• If a plugin offers Edit or AI Edit, use that flow instead of pasting a guessed path by hand.
• If a plugin still fails after saving settings, reload it and then re-check the plugin card for errors.

Related guides

• For installation and lifecycle actions, see Install & Manage Plugins
• For provider ordering, see Image Generation Plugins
• For policy settings, see Runtime Auto-Approve