Hmbown/CodeWhale · error
Automation belongs to another Runtime execution scope
Error message
Automation belongs to another Runtime execution scope
What it means
adopt_for_run binds an automation record to the manager's current execution scope before it can be run. If the record already carries an execution_scope from another runtime, running it here would violate ownership, so it bails. Unscoped records are adopted (stamped with the current scope) on first run.
Solutions
- Run the automation from the runtime whose scope it is bound to
- Clear automation.execution_scope in the stored record (or re-create the automation) so the current runtime can adopt it
- Recreate automations in the new runtime rather than copying state across scopes
Example fix
// before: record JSON contains "execution_scope": "scope-old-runtime"
// after: remove the field so the current runtime adopts it
{"id": "auto_1", "execution_scope": null, "status": "active", ...} Defensive patterns
Strategy: validation
Validate before calling
let bound_scope_ok = automation.execution_scope
.as_deref().map_or(true, |s| Some(s) == manager.execution_scope());
if !bound_scope_ok { return Err(anyhow!("automation owned by another runtime")); } Try / catch
match manager.run(automation_id) {
Err(e) if e.to_string().contains("another Runtime execution scope") => eprintln!("re-create this automation in the current runtime"),
r => r?,
} Prevention
- Don't copy automation state directories between machines/profiles
- Re-create automations after switching runtimes rather than reusing stored records
- Strip execution_scope when exporting/importing automation records
When it happens
Trigger: Calling adopt_for_run (directly or via triggering a run) for an automation whose persisted execution_scope differs from the current manager's execution_scope().
Common situations: State directory copied or synced between machines/profiles so records reference a foreign runtime scope; switching runtimes while reusing stored automations; restore from backup with old scope ids.
Understand the failure class
Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.
Related errors
- Automation admission execution ownership is unverified or…
- Automation service belongs to another Runtime scope
- Automation execution ownership is unverified
- Task not found
- A pinned automation provider requires an explicit model
AI-assisted analysis of Hmbown/CodeWhale@433685b202 (2026-09-15).
Data as JSON: /api/errors/6cc33d56f78768e7.
Report an issue: GitHub.
Appendix: source
Thrown at crates/tui/src/automation_manager.rs:1128
}
pub(crate) fn execution_scope(&self) -> Option<&str> {
self.execution_scope.as_deref()
}
fn eligible_scope(&self, scope: Option<&str>) -> bool {
scope.is_some() && scope == self.execution_scope()
}
/// Explicit control may bind an unbound definition; saved admissions never
/// read this field back from the definition during recovery.
fn adopt_for_run(&self, automation: &mut AutomationRecord) -> Result<()> {
let scope = self
.execution_scope()
.context("Automation execution ownership is unverified")?;
if let Some(bound) = &automation.execution_scope {
if bound != scope {
bail!("Automation belongs to another Runtime execution scope");
}
} else {
automation.execution_scope = Some(scope.to_string());
automation.schema_version = CURRENT_AUTOMATION_SCHEMA_VERSION;
automation.updated_at = Utc::now();
if automation.status == AutomationStatus::Active {
let schedule = AutomationSchedule::parse_rrule(&automation.rrule)?;
automation.next_run_at =
match schedule.next_after_with_anchor(Utc::now(), automation.created_at) {
Ok(next) => Some(next),
Err(_) if matches!(schedule, AutomationSchedule::Once { .. }) => {
automation.status = AutomationStatus::Paused;
None
}
Err(error) => return Err(error),
};
}
self.save_automation_unlocked(automation)?;View on GitHub (pinned to 433685b202)