Stopping Agent Loops: VS Code Copilot and Fork Bombs

Correction note (2026-10-13). The per-call timings and latency figures that appeared in this article had no benchmark behind them and were removed. Sample output in this article is illustrative, not a recorded run. The only published measurement is p50 0.39 ms and p99 1.91 ms (sigmashake-bench daemon-socket run, 2026-06-10, ssg 0.29.156, n=500). Sub-2 ms evaluation is a design target.

Describe the task

VS Code Copilot is generating a background process management script. A subtle bug produces a self-replicating process loop — a fork bomb:

:(){ :|:& };:

SSG detects the pattern and blocks it before your machine becomes unresponsive.

# illustrative sample output
[BLOCK] bash › :(){ :|:& };: — rule: no-fork-bomb

Give SSG context

SSG evaluates VS Code Copilot's shell commands via the SSG MCP Server integration.

Required context

rule no-fork-bomb {
  enabled true
  priority 100
  severity error
  DENY execution
  IF command MATCHES ":\(\)\{.*:\|:.*\}"
  MESSAGE "Fork bomb pattern detected. This command exponentially spawns processes and will crash the system."
}

Optional context

Also catch common while-true spawn loops:

rule no-infinite-spawn {
  enabled true
  priority 90
  severity error
  DENY execution
  IF command MATCHES "while\s+true.*&"
  AND command CONTAINS "sleep 0"
  MESSAGE "Infinite background spawn loop detected. Add a rate limit or exit condition."
}

What SSG does

SSG matches the fork bomb pattern at the command string level before the shell interprets it. No processes are spawned — the system remains stable.

Ask the agent to add exit conditions

Fork bomb pattern blocked. If you need background process management:
  - Use a process manager (pm2, systemd) instead of shell loops
  - Add explicit exit conditions and sleep intervals to any loop
  - Use 'wait' to control background job concurrency
  - Test process spawning logic in a container with ulimits applied

Protect with ulimits as a defense-in-depth

Even with SSG blocking fork bombs, apply system-level ulimits as a second layer:

ulimit -u 200    # max 200 user processes
ulimit -n 1024   # max open file descriptors

Configure these in /etc/security/limits.conf for persistence across sessions.

Audit process spawning patterns

Review ssg dashboard for any commands that create background processes (&, nohup, disown). Unusual process spawning patterns can indicate agent runaway behavior before it becomes a full fork bomb.