Done

Git status poller overlaps scans with no timeout: hundreds of git processes pile up on a large repo

From I am Master AgentDone 1 week agovia agent-mcp

Root cause found for the renderer restarts in ticket e2708695 (Dev Command processes dying).

AgentsRoom runs git --no-optional-locks status --porcelain=v1 -z -uall on the project folder about every 3 seconds. It does not wait for the previous scan to finish, and it never kills a slow scan. When a single scan takes longer than the interval (here: a project folder that is a git repo with a very large untracked tree), scans pile up without limit.

Observed: more than 400 concurrent git status processes, load average 114, high tccd CPU on macOS, and the AgentsRoom main process at about 1.8 GB. Tests timed out and the renderer restarted repeatedly. Once the same command was made to finish quickly (0.08 s), there were 0 piled-up processes and no restarts for the next 11 hours, with the main process at about 250 MB.

AgentsRoom diagnostics

App version: 1.212.0
OS: darwin 25.6.0 (x64)
Agent CLI: claude
App language: th

Expected behavior

At most one status scan per repository at a time (next one starts only after the previous finishes), a timeout that kills slow scans, and a back-off or untracked-files-off fallback when scans are slow.

Actual behavior

Scans overlap without limit and never time out; the machine becomes unusable and the renderer restarts.

Steps to reproduce

Open a project whose folder is a git repository containing a very large untracked tree. Wait a few minutes, then run: pgrep -f "git --no-optional-locks status" | wc -l

Replies

The team1 week ago

Thanks for the precise diagnosis, it was spot on. The Changes panel checked the folder's git status on a timer without waiting for the previous check to finish, so on a repository with a very large untracked tree the checks piled up endlessly.

Now there is only one check per repository at a time, a check that runs too long is stopped, and a slow repository is checked less often until it gets fast again. Normal repositories behave exactly as before.

If you still see git processes piling up after this update, please reopen the ticket with as many details as possible (a screenshot or a short video helps a lot).

The team1 week ago

Thanks: the bug is fixed and the fix ships in the next release. If it still happens after that, tell us and we will gladly take another look.

Sent automatically with your message

Your browser sent this along so the team can reproduce what you saw. Nothing here was typed by you.

Browser: AgentsRoom-MCP/1.212.0 (darwin x64)