[Bug]: Auggie MCP process can survive closed Linux terminal session and contribute to OOM

[H-Ali13381]

Summary

Auggie MCP processes appear to survive after their owning terminal / MCP client session is closed, leaving stale auggie --mcp instances running under old Konsole/systemd tab scopes. In my case this contributed to severe system memory pressure and an OOM event: a stale Hermes/agent session in a supposedly closed Konsole tab reached ~10.8 GiB RSS peak / 6.3 GiB swap peak before the kernel OOM-killed the parent process.

This seems closely related to #63, but I am filing this separately because:

• I am on @augmentcode/auggie 0.24.0, well after the version mentioned as fixed in [Bug]: Auggie CLI MCP Mode Orphaned Processes Enter Infinite CPU Loop #63.
• The observed failure mode is not just an infinite CPU loop; it is stale MCP/client processes surviving terminal/tab closure and contributing to memory exhaustion.
• This happened on Linux/KDE/Konsole with systemd user scopes, not Windows/VSCode.

What happened

After closing a Konsole tab that had been running an AI-agent workflow using Auggie as an MCP server, the system later became sluggish. Kernel logs showed a real OOM event.

Key OOM lines:

Apr 26 22:24:48 <hostname> kernel: threaded-ml invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=200
Apr 26 22:24:48 <hostname> kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=user.slice,mems_allowed=0,global_oom,task_memcg=/user.slice/user-<uid>.slice/user@<uid>.service/app.slice/app-org.kde.konsole-148983.scope/tab(187577).scope,task=hermes,pid=187715,uid=<uid>
Apr 26 22:24:48 <hostname> kernel: Out of memory: Killed process 187715 (hermes) total-vm:12953104kB, anon-rss:11264528kB, file-rss:604kB, shmem-rss:0kB, UID:<uid> pgtables:23940kB oom_score_adj:200

The relevant systemd accounting for the supposedly closed Konsole scope:

Apr 26 22:24:48 <hostname> systemd[751]: app-org.kde.konsole-148983.scope: The kernel OOM killer killed some processes in this unit.
Apr 26 22:24:49 <hostname> systemd[751]: app-org.kde.konsole-148983.scope: Consumed 42min 14.626s CPU time over 2d 1h 53min 46.764s wall clock time, 10.8G memory peak, 6.3G memory swap peak.

The user had already closed that Konsole tab. The key surprise is that processes under the old tab scope were still alive until the OOM killer cleaned them up.

Current live process evidence

After the OOM, I still found other long-running Auggie MCP subprocesses attached to old terminal/session trees:

PID 432412 claude
cgroup: /user.slice/user-<uid>.slice/user@<uid>.service/app.slice/app-org.kde.konsole-380850.scope/tab(380868).scope

PID 432433 node ~/.nvm/versions/node/v24.12.0/bin/auggie --mcp --mcp-auto-workspace
cgroup: /user.slice/user-<uid>.slice/user@<uid>.service/app.slice/app-org.kde.konsole-380850.scope/tab(380868).scope

PID 506832 ~/.hermes/hermes-agent/venv/bin/python3 ~/.local/bin/hermes
cgroup: /user.slice/user-<uid>.slice/user@<uid>.service/app.slice/app-org.kde.konsole-380850.scope/tab(506596).scope

PID 506849 node ~/.nvm/versions/node/v24.12.0/bin/auggie --mcp --mcp-auto-workspace -w ~/Documents
cgroup: /user.slice/user-<uid>.slice/user@<uid>.service/app.slice/app-org.kde.konsole-380850.scope/tab(506596).scope

Process tree excerpt:

konsole,380850
  |-bash,380868
  |   `-claude,432412
  |       `-MainThread,432433 ~/.nvm/versions/node/v24.12.0/bin/auggie --mcp --mcp-auto-workspace
  `-bash,506596
      `-hermes,506832 ~/.local/bin/hermes
          `-MainThread,506849 ~/.nvm/versions/node/v24.12.0/bin/auggie --mcp --mcp-auto-workspace -w ~/Documents

Why I think Auggie is involved

The killed process was the parent agent process (hermes), not the Auggie child itself. However, the workflow was using Auggie MCP heavily (auggie --mcp --mcp-auto-workspace) for codebase retrieval, and stale Auggie MCP children are observable in surviving old session trees.

So the immediate OOM victim was Hermes, but the lifecycle bug appears to be in the MCP/process tree behavior: when the terminal/client session is closed, the Auggie MCP process and/or its client-side tree should terminate cleanly rather than leaving a long-lived session capable of accumulating resources.

This is similar in spirit to #63: MCP server processes do not reliably die when the parent/client disconnects. The difference here is that it is reproducible/observable on Linux with Auggie 0.24.0 and manifests as stale Konsole tab scopes plus memory pressure/OOM rather than only CPU spin.

Expected behavior

When the owning terminal tab, MCP client, or parent process closes/disconnects:

1. auggie --mcp should detect stdin EOF / stdio pipe closure / parent death.
2. It should shut down promptly.
3. Any spawned helper/indexing/workspace processes should be terminated or reparented only intentionally.
4. No stale auggie --mcp process should remain under an old terminal tab/systemd scope.

Actual behavior

A supposedly closed Konsole tab's systemd scope remained alive until an OOM event:

app-org.kde.konsole-148983.scope/tab(187577).scope

That scope reached:

10.8G memory peak
6.3G swap peak

and the kernel killed the Hermes process in that scope.

Other Auggie MCP children remained observable under older terminal process trees.

Environment

• OS: Arch Linux
• Kernel: 6.19.12-arch1-1
• Desktop: KDE Plasma 6 Wayland / Konsole
• Shell: bash
• Node: v24.12.0
• Auggie package: @augmentcode/auggie version 0.24.0
• Auggie binary: ~/.nvm/versions/node/v24.12.0/bin/auggie
• Invocation observed:

node ~/.nvm/versions/node/v24.12.0/bin/auggie --mcp --mcp-auto-workspace -w ~/Documents
node ~/.nvm/versions/node/v24.12.0/bin/auggie --mcp --mcp-auto-workspace

Diagnostics that may help

The kernel reported threaded-ml invoked oom-killer, but I believe that is not the root cause. KDE/Qt processes on this machine have threads named threaded-ml:

kded6       threaded-ml
plasmashell threaded-ml
konsole     threaded-ml

So that thread likely merely triggered the allocation that discovered global OOM. The OOM victim selection chose the high-memory Hermes process.

Suggested areas to inspect

• MCP stdio server shutdown on stdin EOF / close.
• Handling of SIGHUP/SIGTERM/SIGINT in MCP mode.
• Whether child processes/helpers spawned by --mcp-auto-workspace are bound to parent lifecycle.
• Linux parent-death handling (prctl(PR_SET_PDEATHSIG, SIGTERM) equivalent via a small wrapper or explicit parent PID monitor) if Node signal/stdio handling is insufficient.
• Any retry/read loop in MCP mode that continues after stdio disconnect.

Workaround

Manually inspect and kill stale Auggie MCP trees:

ps -eo pid,ppid,stat,pcpu,pmem,rss,etime,comm,args | grep -Ei 'auggie|hermes|claude'
pstree -aps <konsole-or-parent-pid>
kill <stale-parent-pid>

For example, in my current session one stale-ish tree is:

kill 432412

which should also terminate its child Auggie MCP process.

Related

• [Bug]: Auggie CLI MCP Mode Orphaned Processes Enter Infinite CPU Loop #63 [Bug]: Auggie CLI MCP Mode Orphaned Processes Enter Infinite CPU Loop