Deleting RLM subagents races with completion on Windows: repeated EPERM and a hidden live session

[telemetrya2018-dotcom]

Summary

On Windows with Prime Agent 0.8.1, deleting an RLM child can race with child completion/state persistence. The atomic write of rlm-subagent.json repeatedly fails with EPERM. A child can disappear from rlm.list_subagents() while its daemon session remains live, causing repeated cleanup errors and delayed failure notifications.

This was reproduced with two different children in one parent session. One child produced multiple new EPERM events even after delete_subagent() had returned successfully.

Error

Sanitized path:

Deletion cleanup failed; retry rlm.delete_subagent("<child-id>") before completion:
EPERM: operation not permitted, rename
'D:\PrimeAgent\data\session-artifacts\<parent>\<child>\rlm-subagent.json.tmp-<pid>-<timestamp>'
->
'D:\PrimeAgent\data\session-artifacts\<parent>\<child>\rlm-subagent.json'

Observed behavior

Child A

1. Parent requested deletion of a running research child.
2. Persistence failed with EPERM during temp-file rename.
3. Repeating rlm.delete_subagent(childId) succeeded immediately.
4. The child disappeared from the RLM roster.

Child B

1. Parent requested deletion of a running smoke-test child.
2. delete_subagent() returned success, but the returned object still reported status="running".
3. The child disappeared from rlm.list_subagents().
4. Multiple later cleanup attempts generated new EPERM errors with distinct .tmp-<pid>-<timestamp> filenames.
5. prime-agent list --all --json still showed the supposedly deleted child session as:

{
  "lifecycle": "live",
  "activity": "idle",
  "runtimeKind": "subagent",
  "taskState": "needs_input"
}

6. The persisted rlm-subagent.json also remained stale with "status": "running".
7. The only effective workaround was to find the hidden active daemon session and run:

prime-agent stop <active-session-id> --json

That returned success: true and changed the session lifecycle to archived.

No temporary .tmp-* files remained after the successful retry, but state across the RLM roster, daemon session registry, and metadata file was inconsistent.

Likely race

The evidence is consistent with a race between:

• parent-orchestrated deletion;
• child completion/final status persistence;
• daemon session lifecycle cleanup;
• Windows rename semantics when the destination is open or concurrently replaced.

This is a hypothesis about the code path, not a claim about which process held the file handle.

Steps to reproduce

1. On Windows, spawn an RLM child that is still running or about to finish.
2. Call await rlm.delete_subagent(child) while completion/final messaging is in flight.
3. Observe an EPERM rename failure for rlm-subagent.json.tmp-* -> rlm-subagent.json.
4. Retry deletion.
5. Compare rlm.list_subagents() with prime-agent list --all --json.
6. Watch for delayed cleanup notifications after the child has disappeared from the RLM roster.

The race may be easier to reproduce when Windows Defender, indexing, or another reader briefly opens the metadata file, but no handle owner was proven in this report.

Expected behavior

• delete_subagent() is idempotent and does not return until the child is stopped or durably marked deleted.
• A successful return means the child is absent from both the RLM roster and daemon live-session registry.
• Child finalization cannot write a new running state after deletion begins.
• Atomic state persistence retries transient Windows EPERM/EACCES/EBUSY failures with bounded backoff.
• If replacement by rename is unsafe on Windows, use a Windows-appropriate replace strategy.
• Repeated cleanup callbacks are coalesced and do not generate duplicate user-facing failure notifications.
• A retry can reconcile stale state instead of creating another conflicting persistence attempt.

Related reports

This appears to be a new subagent-deletion path, but similar Windows rename/locking classes were reported in:

• [Bug] Bootstrap lock reclaims stale locks non-atomically, allowing concurrent venv rebuilds #1767
• [Bug] Windows: session lease can be permanently stuck, and a live lease can be reclaimed when owner.json is briefly unreadable #1478
• Interrupted settings saves can leave invalid JSON #1431
• Kernel dispose() returns before the kernel exits, leaving its working directory locked on Windows #1049

Environment

• Prime Agent: 0.8.1
• OS: Windows
• Mode: interactive UI + daemon + RLM children

[telemetrya2018-dotcom]

Additional reproducible lifecycle/reply-tracking inconsistency:

• The filesystem-audit child could not use the injected Python agent_message skill (No module named 'agent_message').
• It fell back to prime-agent send and delivered the report in two parts; the parent received both parts and also read the complete on-disk report.
• After the child was stopped and deleted, the UI still emitted completed without sending a reply.

So the completion monitor reported a false negative: daemon CLI delivery succeeded, but RLM reply tracking did not recognize that delivery path (or did not reconcile it before cleanup). No report data was lost. This is another example of the daemon/RLM/UI lifecycle views disagreeing.