Stopping Agent Loops: Windsurf and Fork Bombs

Correction note (2026-10-13). An earlier version of this article said blocked commands are written to a file named ~/.ssg/audit.log. No such file exists. The local audit log is the audit_log table in ~/.sigmashake/rules.db, and ssg audit search reads it. 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. The local audit log records decisions on a best-effort basis: entries can be dropped if the daemon queue is full, and old rows are deleted at the row caps. It is local, not append-only, and not immutable. ssg eval reads the tool call as JSON on stdin and has no --content, --content-file, --file or positional form.

Describe the task

You ask Windsurf to write a load-testing script that spawns multiple workers. The agent produces a shell function containing the classic fork bomb pattern:

:(){ :|:& };:

A fork bomb fills the process table and exhausts system resources until the machine becomes unresponsive or crashes. SSG's no-fork-bomb rule detects the pattern before the script executes.

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

Give SSG context

SSG evaluates Windsurf's shell tool calls via the SSG MCP Server integration inside Windsurf (Cascade).

Required context

rule no-fork-bomb {
  enabled true
  priority 100
  severity error
  DENY execution
  IF command CONTAINS ":(){ :|:&"
  OR command REGEX "\(\)\s*\{.*\|.*\&"
  MESSAGE "Fork bomb pattern detected. This would crash your system."
}

Optional context

Add detection for common variations:

rule no-process-flood {
  enabled true
  priority 90
  severity error
  DENY execution
  IF command REGEX "while\s+true.*&.*done"
  OR command CONTAINS "yes |"
  MESSAGE "Unbounded process spawning detected."
}

What SSG does

SSG matches the fork bomb signature in the raw command string before any child processes are created. The block fires in the agent's tool evaluation layer — your shell never sees the command.

Ask the agent for a safe alternative

The fork bomb pattern was blocked. For load testing with multiple workers,
use a proper process pool like GNU parallel or xargs -P with a fixed concurrency limit.

Monitor for unusual process spawning patterns

Even without a textbook fork bomb, agents can overwhelm systems with unbounded loops. Use SSG's ASK mode to flag any command with & (background spawning) in loops:

rule ask-background-spawn {
  enabled true
  priority 60
  severity info
  ASK execution
  IF command CONTAINS "while " AND command CONTAINS " &"
  PROMPT "Background process spawning inside a loop. Confirm concurrency limit?"
  MESSAGE "Background process spawning inside a loop. Confirm concurrency limit?"
}

Check the audit trail for runaway sessions

Blocked commands are recorded on a best-effort basis in the local audit log (the audit_log table in ~/.sigmashake/rules.db). List them with ssg audit search --decision block --since 24h. If an agent session spawned multiple near-miss patterns before the block, you can trace the sequence in those rows or in ssg dashboard.

How your pattern shapes what gets caught

The regex \(\)\s*\{.*\|.*\& catches obfuscated variants with whitespace between the function body. Start with the literal match for the classic form, then add regex variants as you encounter them.

Check the rule against your test scripts

Legitimate stress test scripts use parallel, xargs -P, or explicit for loops with a counter. These don't match the fork bomb pattern. If you have scripted load tests, run echo '{"tool":"Bash","input":{"command":"xargs -P 8 ./load_test.sh"}}' | ssg eval to verify they pass without triggering the rule.