Skip to main content

own_instance_pids

Function own_instance_pids 

Source
pub(crate) fn own_instance_pids() -> HashSet<u32>
Expand description

PIDs CaptureWindow must treat as “this agent’s own AgentMux instance” and always exclude — reagent P0 (PR #2709 round 3).

Primary signal: AGENTMUX_APP_PATH. Every process belonging to this exact running instance (portable build or install) is launched from under that one directory — confirmed directly (not assumed): this agent’s own host process’s Process::exe() path (...\agentmux-0.55.18+....-x64-portable\runtime\agentmux-0.55.18.exe) starts with AGENTMUX_APP_PATH (...\agentmux-0.55.18+....-x64-portable) exactly. This is more precise than matching on version number alone — it correctly tells apart two separate instances that happen to share a version (e.g. two portable builds of the same release), which a version-string match would conflate.

Fallback signal: bounded process-ancestor walk. Kept as a second, additive layer (union, not replacement) for the case AGENTMUX_APP_PATH isn’t set (confirmed present for AGENTMUX_RUNTIME_MODE=portable; not separately confirmed for task dev instances). This alone is not reliable — verified directly by testing: Windows recycles PIDs and a process’s recorded parent-PID can point at an already-exited process, so sys.process(stale_ppid) returns None and the walk silently stops short of the real ancestor chain. Confirmed this exact failure in testing (the walk never reached this instance’s own host process). Kept only as defense-in-depth alongside the path-based signal, never alone.

Fails safe: an unresolvable pid() on a candidate window (checked by the caller, CaptureWindow’s handler) is treated as “assume it’s mine, exclude it” — so a window this function’s own signals can’t positively place is still excluded, not silently let through.