Runtime preferences and auto sync
Control how each runtime syncs agents and how runtime-level mission instructions are applied.
Runtime preferences let you decide how each connected machine behaves when ClawControl scans for agents and applies mission-level instructions.
What runtime preferences control
The preferences area is where you manage two important behaviors for each paired runtime:
- whether ClawControl should auto-sync eligible agents on that runtime
- what standing mission instructions that runtime should follow
This is useful when different machines have different purposes, ownership, or levels of trust.
What auto sync does
When auto sync is turned on, ClawControl periodically scans that runtime and applies the sync policy to import or update eligible agents automatically.
In practical terms, that means ClawControl can:
- discover newly eligible agents on the host
- keep managed agents aligned with expected settings
- record the last run result, counts, and failures for that runtime
When to turn auto sync on
Auto sync is a good fit when:
- the runtime is stable and always meant to stay connected to ClawControl
- you want existing agents on that machine to stay aligned over time
- you do not want to run manual import checks every time the host changes
When manual sync is the better choice
Keep auto sync off when:
- you are still reviewing the machine for the first time
- you want to inspect imported defaults carefully before adoption
- the runtime is temporary, experimental, or shared for unrelated work
Manual sync gives you a review checkpoint before changes are applied.
Why some LEAD imports are held back
Auto sync is intentionally more careful with default agents that look like LEAD candidates.
If the SOUL guidance does not clearly match coordinator behavior, ClawControl can skip the import and tell you to review it manually. This helps prevent a default agent from being auto-adopted as a LEAD with the wrong instructions.
Understanding the mission policy
Mission policy is the runtime-level instruction set that ClawControl resolves for that runtime during sync and coordination flows.
You can think of it as the runtime's standing mission statement. It is not a single task prompt. It is a persistent instruction layer that tells the runtime how to behave at a higher level.
Typical uses include:
- telling a runtime what kind of environment it represents
- defining local coordination rules for agents on that machine
- overriding the default mission for one runtime without changing the whole workspace
How mission policy sources work
Mission policy can come from more than one place.
- If you set a runtime-specific override, that runtime uses it.
- If you do not, ClawControl can fall back to an organization default.
- If neither exists, the runtime has no mission policy applied.
This lets teams keep a common default while still giving important runtimes their own instructions.
Good mission policy guidance
- Keep it stable and high level
- Use it for standing behavior, not one-off task requests
- Review it when a runtime changes purpose
- Keep runtime-specific overrides short enough that operators can audit them quickly