Configuration Sync to Git

The Workspace can mirror its administrative configuration — schemas, roles, permissions, connectors, scheduled tasks and other definitions — into a Git repository. Every change made by an admin is committed automatically, with the author and an optional message attached. When a remote is configured, the same commits are pushed upstream so the repository becomes the audit trail and the disaster-recovery copy of the workspace configuration.

Use it to:

• Track who changed which configuration setting, and when.
• Promote configuration from staging to production by pulling the same commits into another workspace.
• Recover a known-good configuration after a misconfiguration or a restore.

How it works

On startup, when MSK_GIT_TRACK_STATE_PATH is set, the workspace opens (or initializes) a Git repository at that path and checks out the configured branch. From then on, every tracked administrative change triggers an export of the current configuration into the repository's definitions/ folder, followed by a commit with the author set to the user who made the change.

If MSK_GIT_REMOTE_URL is also set, the workspace pushes the branch upstream after each commit using the supplied credentials.

Required environment variables

Credentials

Use a service account or a personal access token scoped to the single configuration repository — not a long-lived user credential.

• GitHub: a fine-grained PAT with Contents: read & write on the target repository works as the password. Set MSK_GIT_REMOTE_USERNAME to any non-empty string (GitHub ignores it for PAT auth).
• GitLab: a project access token with the Developer role and the write_repository scope.
• Azure DevOps: a PAT with Code: Read & Write. Use the PAT as the password.

What ends up in the repository

The first commit on a fresh repository contains only a README.md placeholder. Subsequent commits add and update files under definitions/. The full layout is regenerated from the live workspace on every change, so the working tree always reflects the workspace's current configuration — there are no partial edits.

The tree mirrors the definitions export:

A few of those carry rules worth knowing before you read a diff:

• Chat policies get one file per policy under config/chat-policies, written as the same definition the admin interface edits, with enum values written as names so a diff stays readable. The built-in policies are seeded from code on every boot and stay out of the repository.
• Chat-policy enforcement settings — everything governing the batched sweep — live in config/chat-policy-enforcement.json.
• Deep research maximum limits (concurrent runs, queued runs, concurrent runs per user, iterations, duration) ride along in config/general.json.
• Secrets export their declaration only: name and description, under config/secrets. The value is written as the literal NOT EXPORTED, so a reader of the file or of the diff can see it was withheld rather than missed. Declarations travel because code that reads a secret only compiles where the declaration exists.
• Custom AI assistants carry their chat prompt, the tools, agents and skills they pin, and whether they are shared. The built-in admin assistant is seeded from code and stays out.
• The built-in consult tool is exported once a workspace has edited it; a workspace still running the shipped code re-seeds it on boot instead.

Each commit message follows the pattern:

Configuration Sync (<optional context provided by the change>)

The author is the user who triggered the change (full name and email taken from their workspace profile). The committer is always the Curiosity Workspace service identity.

Importing the definitions into another workspace

Promoting a configuration means feeding the same definitions/ tree into the target workspace as a definitions bundle. What the import does with it:

• Overwriting an existing definition is recorded. An import that replaces an endpoint, AI tool, prompt template, entity post-processing, code / data-connector / migration task, AI provider, agent or skill leaves the same change-history entry a hand edit does, attributed to whoever ran the import, so the change can be reviewed, diffed and rolled back from the History view. Creating a definition the workspace did not have is deliberately not recorded — there is nothing to diff against.
• A live secret is never overwritten. A secret the target already has is left completely untouched, values included. A secret it lacks is created with an empty value and named in the import warnings; set its value under Manage → Configure → Secrets before the code that reads it runs.
• An assistant may pin something the target lacks. If an imported AI assistant pins a tool, agent or skill that is not in the target workspace, the assistant is imported and the missing item is reported as a warning rather than failing the whole bundle. Include the pinned definitions in the same bundle to avoid it.

Two import failure modes that no longer occur: a tool or agent whose description spans several paragraphs used to break the parse of its file and fail the entire import, and skills could not be created or renamed through the WebDAV definitions mount at /dav/ because the folder was missing from its layout.

Troubleshooting

See also: Configuration, Security, Backup and restore.