Organization configuration can be exported as a portable bundle and applied to another organization. Find it under Settings → Data → Export settings.
This exists for three situations: standing up a second organization that should match an existing one, promoting a configuration from a trial workspace to a real one, and keeping a reviewable record of how a workspace is configured.
What travels
The bundle covers organization-level configuration:
| Area | Included |
|---|---|
| Policy and quality | Org policy, quality policies, project gates, lifecycle policies, review rules |
| Delivery | Mandates: what autonomous work is for (objective, target, priorities, scope, budget per window, stopping conditions, review date, drift rule, owner role). Baselines are measurements and stay; an import creates drafts for a person to publish |
| Agents and models | AI profiles, provider key references |
| Automation | Hooks, schedules |
| Connections | Source control integrations, channel bridges, MCP servers |
| Access | Enterprise identity configuration, service accounts and whether each one starts qualified work automatically |
| Data | Retention settings, storage configuration, audit destinations |
An import creates no service accounts. An account that already exists under the same name takes the bundle's choice of whether its qualified work starts automatically.
What does not travel
Secrets never leave. Provider keys, tokens and credentials are exported as placeholders. The bundle records that a key exists and what uses it, never its value — you re-enter secrets after importing.
Also excluded: anything that is workspace identity rather than configuration — the organization name, its members, its billing relationship — and operational history such as tasks, runs and audit events.
The rule is that a bundle describes how a workspace is configured, not what has happened in it.
Applying a bundle
The portal exports bundles but does not import them. To apply one, connect an agent such as Hermes to Coroid's MCP server. The agent previews the bundle and then applies it. It can also configure an organization from screenshots, files or a description, by writing them into a bundle first.
Applying needs a connection that belongs to an owner, and an owner or administrator approves every apply. On coroid.ai, these administration tools are not switched on yet. See Organization settings over MCP.
Preview before applying
Applying a bundle runs a preview first, showing what each section would do:
| Status | Meaning |
|---|---|
applied | The setting will be created or updated |
unchanged | Already matches; nothing to do |
needsRebind | Depends on something that must be re-pointed locally |
failed | Cannot be applied; the reason is given |
Read the preview properly. needsRebind is the one that matters most — it flags
settings referring to something that does not exist identically in the target,
typically a repository connection or a secret. Those need attention before the
configuration is actually equivalent.
Settings bundle
- Policy and quality
- AI profiles
- Hooks and schedules
- Connections
••••••Secrets become placeholders
Preview in the target organization
- AI profilesWill be created or updatedapplied
- Quality policiesAlready matchesunchanged
- Source control integrationRe-point to a local connection and re-enter its secretneedsRebind
- HooksCannot be applied; the reason is shownfailed
Keeping bundles in version control
An exported bundle is a file, so it can live in a repository, be diffed and be reviewed. For teams treating configuration as code, that is the value: a change to organization policy becomes a reviewable diff rather than a click someone made.
Since secrets are placeholders, a bundle is safe to commit — but check for anything identifying in your own configuration before making one public.