Summary
After running the ruflo-machine-ref install, Claude Code sessions start crashing repeatedly — the process stops completely and requires a full restart. Investigation traced three root causes introduced by the install.
Root Cause 1: Daemon processes fill the Claude Code sandbox tmpfs
Claude Code runs subprocess outputs through a size-limited sandbox tmpfs at /private/tmp/claude-501/<project>/tasks. The install starts ruflo daemon processes (via ruflo-setup-project → ruflo daemon start) that spawn background workers (audit, optimize, ultralearn, deepdive, consolidate, etc.) on 30–60 minute schedules. Combined with the existing per-prompt and per-Bash hooks in .claude/settings.json, the volume of subprocess I/O fills the sandbox to 0 MB free.
Exact error seen in Claude Code:
the temp filesystem at /private/tmp/claude-501/-Users-lyle-dev-SynOrca/<uuid>/tasks
is full (0MB free). The child process's stdout/stderr writes failed with ENOSPC.
This is what causes the session crash — Claude Code cannot write hook/tool output and terminates.
Root Cause 2: statusline.cjs injection runs sqlite3 queries on every render (no timeout)
install.sh injects a rufloActivationSegments() block into the project's .claude/helpers/statusline.cjs (between /* ruflo-seg:BEGIN */ and /* ruflo-seg:END */ markers) and appends a call to it on the statusline output line:
console.log(generateStatusline() + rufloActivationSegments(process.cwd()));
This function runs up to 5 sqlite3 subprocess calls (each with a 1500ms timeout) on every statusline render. The project's settings.json configures the statusline with no timeout:
"statusLine": { "type": "command", "command": "node .claude/helpers/statusline.cjs" }
If sqlite3 is slow or the database is locked, this hangs indefinitely.
Root Cause 3: daemon.autoStart: true in settings.json
The project settings.json has claudeFlow.daemon.autoStart: true, meaning the daemon restarts automatically on every Claude Code session open. This ensures Root Cause 1 re-occurs after every restart.
Steps to Reproduce
- Clone a project that uses claude-flow V3 hooks (
.claude/settings.json with UserPromptSubmit, PreToolUse, PostToolUse hooks)
- Run ruflo-machine-ref install
- Open Claude Code in that project
- Use it for a while — sessions will crash within minutes
Fix Applied
# Kill daemon processes
kill <daemon-pids>
# Remove ruflo-seg injection from statusline.cjs
python3 -c "
import re
with open('.claude/helpers/statusline.cjs') as f: c = f.read()
c = re.sub(r'/\* ruflo-seg:BEGIN \*/.+?/\* ruflo-seg:END \*/\n', '', c, flags=re.DOTALL)
c = c.replace('generateStatusline() + rufloActivationSegments(process.cwd())', 'generateStatusline()')
with open('.claude/helpers/statusline.cjs', 'w') as f: f.write(c)
"
# Disable daemon autoStart
python3 -c "
import json
with open('.claude/settings.json') as f: s = json.load(f)
s['claudeFlow']['daemon']['autoStart'] = False
with open('.claude/settings.json', 'w') as f: json.dump(s, f, indent=2)
"
# Set CLAUDE_CODE_TMPDIR to main filesystem in ~/.claude/settings.json
# \"env\": { \"CLAUDE_CODE_TMPDIR\": \"/Users/<you>/tmp/claude-code\" }
Suggestions
install.sh should not inject into statusline.cjs without a configurable timeout guard, or should skip the injection if the statusline has no timeout configured.
- The daemon should default to
autoStart: false — it should be opt-in.
- The install should document the
CLAUDE_CODE_TMPDIR workaround for users with many hooks.
- Consider whether starting a daemon with 10 background workers is appropriate as a side effect of
ruflo-setup-project.
Environment
- macOS Darwin 25.5.0
- Claude Code (claude-sonnet-4-6)
- ruflo-machine-ref installed 2026-05-29
Summary
After running the ruflo-machine-ref install, Claude Code sessions start crashing repeatedly — the process stops completely and requires a full restart. Investigation traced three root causes introduced by the install.
Root Cause 1: Daemon processes fill the Claude Code sandbox tmpfs
Claude Code runs subprocess outputs through a size-limited sandbox tmpfs at
/private/tmp/claude-501/<project>/tasks. The install starts ruflo daemon processes (viaruflo-setup-project→ruflo daemon start) that spawn background workers (audit, optimize, ultralearn, deepdive, consolidate, etc.) on 30–60 minute schedules. Combined with the existing per-prompt and per-Bash hooks in.claude/settings.json, the volume of subprocess I/O fills the sandbox to 0 MB free.Exact error seen in Claude Code:
This is what causes the session crash — Claude Code cannot write hook/tool output and terminates.
Root Cause 2:
statusline.cjsinjection runs sqlite3 queries on every render (no timeout)install.shinjects arufloActivationSegments()block into the project's.claude/helpers/statusline.cjs(between/* ruflo-seg:BEGIN */and/* ruflo-seg:END */markers) and appends a call to it on the statusline output line:This function runs up to 5
sqlite3subprocess calls (each with a 1500ms timeout) on every statusline render. The project'ssettings.jsonconfigures the statusline with no timeout:If sqlite3 is slow or the database is locked, this hangs indefinitely.
Root Cause 3:
daemon.autoStart: trueinsettings.jsonThe project
settings.jsonhasclaudeFlow.daemon.autoStart: true, meaning the daemon restarts automatically on every Claude Code session open. This ensures Root Cause 1 re-occurs after every restart.Steps to Reproduce
.claude/settings.jsonwithUserPromptSubmit,PreToolUse,PostToolUsehooks)Fix Applied
Suggestions
install.shshould not inject intostatusline.cjswithout a configurable timeout guard, or should skip the injection if the statusline has no timeout configured.autoStart: false— it should be opt-in.CLAUDE_CODE_TMPDIRworkaround for users with many hooks.ruflo-setup-project.Environment