Context
PR #5224 retains one official ACP child process per Maka conversation after its first prompt, including while the conversation waits for the next turn. This is the PR 2 continuity rule in #5103: closing the Desktop UI does not retire the task. Task retirement and Plugin/Host teardown release owned process trees, but PR 2 has no idle timeout or process-count cap. A long-running Host can therefore accumulate child processes.
PR 2 records this operational limit rather than evicting a usable task into history_only. PR 3 in #5103 owns restoration of the same external Session after process loss; it does not itself commit to a process-retention policy.
Decision and follow-up
After PR 3 establishes the real Agent's restore behavior, decide how to bound ACP client process retention. Compare an idle timeout, an LRU/process cap, an admission cap, or a combination. Account for process and helper resources, multiple Maka conversations, active prompts and model changes, cancellation, and tasks whose history remains readable after their process is retired. Define the user-visible readiness and continuation behavior before implementing eviction.
Acceptance criteria
- Document the chosen limit, its rationale, and the effect of reaching it.
- No active prompt, configuration change, or process cleanup races with retirement.
- Retiring a process terminates its owned tree and releases in-memory ownership.
- A retired conversation either restores the same external Session or clearly reports that continuation is unavailable; it never silently creates a replacement Session.
- Add controlled-process tests for the selected policy and its boundary cases.
Refs #5103 and #5224. This issue is separate from PR 3's restoration deliverable.
Context
PR #5224 retains one official ACP child process per Maka conversation after its first prompt, including while the conversation waits for the next turn. This is the PR 2 continuity rule in #5103: closing the Desktop UI does not retire the task. Task retirement and Plugin/Host teardown release owned process trees, but PR 2 has no idle timeout or process-count cap. A long-running Host can therefore accumulate child processes.
PR 2 records this operational limit rather than evicting a usable task into
history_only. PR 3 in #5103 owns restoration of the same external Session after process loss; it does not itself commit to a process-retention policy.Decision and follow-up
After PR 3 establishes the real Agent's restore behavior, decide how to bound ACP client process retention. Compare an idle timeout, an LRU/process cap, an admission cap, or a combination. Account for process and helper resources, multiple Maka conversations, active prompts and model changes, cancellation, and tasks whose history remains readable after their process is retired. Define the user-visible readiness and continuation behavior before implementing eviction.
Acceptance criteria
Refs #5103 and #5224. This issue is separate from PR 3's restoration deliverable.