ralph ends early

[richardrl]

richard@richard-TRX50-AERO-D:~/continual_learning_for_manipulation/.ralph$ ralph --circuit-status
╔════════════════════════════════════════════════════════════╗
║           Circuit Breaker Status                          ║
╚════════════════════════════════════════════════════════════╝
State:                 ✅ CLOSED
Reason:                
Loops since progress: 0
Last progress:        Loop #0
Current loop:         #null
Total opens:          0

Despite there being many remaining steps in fix_plan.md, ralph ends. Why?

[coderabbitai]

🔗 Related PRs

#140 - fix: Recognize STATUS: COMPLETE as progress in circuit breaker [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[github-actions]

Thanks for the report! This has been triaged as a bug 🐛 and assigned to the maintainer.

Summary: Ralph exits early even though the circuit breaker is CLOSED and fix_plan.md still has remaining steps.

Likely causes to investigate:

1. False-positive exit detection — The loop's completion indicator logic (recent_completion_indicators >= 2 + EXIT_SIGNAL: true) may be triggering incorrectly. Claude's response may contain language patterns that look like completion signals even when work remains.

2. fix_plan.md parsing — The checklist completion check may be incorrectly counting all items as done (e.g., if formatting differs from what the parser expects).

3. Done signals — The done_signals >= 2 path (which doesn't require EXIT_SIGNAL) may be firing based on Claude's output text.

To help debug, you can check these files in your .ralph/ directory:

• .ralph/.response_analysis — look at exit_signal, work_type, and completion_indicators values from the last loop
• .ralph/logs/ — review the last loop's output for any EXIT_SIGNAL: true or repeated "done" patterns in Claude's response
• .ralph/fix_plan.md — verify the unchecked items are in the expected - [ ] task format

If you can share the contents of .ralph/.response_analysis and the last log file, that would help pinpoint the exact exit path being triggered.

Generated by Issue Triage Assistant for issue #194

[traycerai]

Plan

Observations

The circuit breaker status showing Current loop: #null is the smoking gun: record_loop_result() (called inside execute_claude_code()) was never invoked, meaning the loop exited before any Claude execution happened. The only pre-execution exit path in the while true loop is should_exit_gracefully() returning a non-empty string.

should_exit_gracefully() reads .ralph/.exit_signals for stale completion signals from a prior run. reset_session() clears this file, but it is not called in the API-limit "user chose exit" path (lines 1736–1739 of ralph_loop.sh) — a plain break is used instead. A SIGKILL/crash also bypasses the trap. On the next ralph invocation, the stale signals immediately trigger a graceful exit before loop #1 executes.

Approach

Fix the three layers of the problem: (1) ensure EXIT_SIGNALS_FILE is always cleared at startup so stale state from any prior run cannot cause an immediate exit, (2) plug the specific missing reset_session() call in the API-limit exit path, and (3) fix the cosmetic #null display in --circuit-status by initialising current_loop in the state file.

---

Implementation Steps

1. Reset EXIT_SIGNALS_FILE unconditionally at startup — file:ralph_loop.sh

In main(), immediately before the while true loop (around line 1607), add an unconditional reset of .ralph/.exit_signals to an empty-arrays JSON object. This is the primary fix: regardless of how the previous run ended, every new invocation of ralph starts with a clean exit-signal slate.

Also emit a log_status "INFO" message so the reset is visible in .ralph/logs/ralph.log.

The existing guard in init_call_tracking() (if [[ ! -f "$EXIT_SIGNALS_FILE" ]]) only creates the file when absent; it must remain as-is for the per-loop initialisation path, but the startup reset above supersedes it for the first iteration.

---

2. Call reset_session() in the API-limit "user chose exit" path — file:ralph_loop.sh

At lines 1736–1739, before the break in the if [[ "$user_choice" == "2" ]] branch, add a call to reset_session "api_limit_exit". This mirrors every other exit path in the loop and ensures EXIT_SIGNALS_FILE and RESPONSE_ANALYSIS_FILE are cleaned up when the user explicitly exits due to the 5-hour API limit.

# Before:
if [[ "$user_choice" == "2" ]]; then
    log_status "INFO" "User chose to exit. Exiting loop..."
    update_status ...
    break
fi

# After:
if [[ "$user_choice" == "2" ]]; then
    log_status "INFO" "User chose to exit. Exiting loop..."
    reset_session "api_limit_exit"          # ← add this
    update_status ...
    break
fi

---

3. Fix Current loop: #null display — file:lib/circuit_breaker.sh

3a. Initialise current_loop in the state file.
In both init_circuit_breaker() (the cat > "$CB_STATE_FILE" heredoc, ~line 46) and reset_circuit_breaker() (~line 409), add "current_loop": 0 to the JSON object. This ensures the field is always present after a fresh init or manual reset.

3b. Use a fallback in show_circuit_status().
At line 372, change:

local current_loop=$(echo "$state_data" | jq -r '.current_loop')

to:

local current_loop=$(echo "$state_data" | jq -r '.current_loop // "N/A"')

This prevents #null from appearing even against old state files that predate the fix.

---

4. Add a diagnostic hint to should_exit_gracefully() — file:ralph_loop.sh

At the top of should_exit_gracefully() (~line 494), add a log_status "INFO" line that logs the current contents of done_signals and completion_indicators lengths. This makes it trivial to diagnose the trigger condition from .ralph/logs/ralph.log in future reports without needing to reproduce the issue.

---

Flow after the fix

sequenceDiagram
    participant User
    participant main() as main()
    participant ESF as .exit_signals
    participant loop as while loop
    participant exec as execute_claude_code()

    User->>main(): ralph --monitor
    main()->>ESF: reset to empty arrays (NEW)
    main()->>loop: enter while true
    loop->>loop: should_exit_gracefully()
    loop-->>exec: no stale signals → proceeds
    exec->>exec: record_loop_result() sets current_loop

Loading

Without the fix, the stale done_signals in ESF caused should_exit_gracefully() to return "completion_signals" immediately, breaking before execute_claude_code() was ever called — leaving current_loop as null.

Import In IDE

🤖 Prompt for AI Agents

## Observations

The circuit breaker status showing `Current loop: #null` is the smoking gun: `record_loop_result()` (called inside `execute_claude_code()`) was **never invoked**, meaning the loop exited before any Claude execution happened. The only pre-execution exit path in the `while true` loop is `should_exit_gracefully()` returning a non-empty string.

`should_exit_gracefully()` reads `.ralph/.exit_signals` for stale completion signals from a prior run. `reset_session()` clears this file, but it is **not called** in the API-limit "user chose exit" path (lines 1736–1739 of `ralph_loop.sh`) — a plain `break` is used instead. A SIGKILL/crash also bypasses the `trap`. On the next `ralph` invocation, the stale signals immediately trigger a graceful exit before loop #1 executes.

## Approach

Fix the three layers of the problem: (1) ensure EXIT_SIGNALS_FILE is always cleared at startup so stale state from any prior run cannot cause an immediate exit, (2) plug the specific missing `reset_session()` call in the API-limit exit path, and (3) fix the cosmetic `#null` display in `--circuit-status` by initialising `current_loop` in the state file.

---

## Implementation Steps

### 1. Reset `EXIT_SIGNALS_FILE` unconditionally at startup — `file:ralph_loop.sh`

In `main()`, immediately **before** the `while true` loop (around line 1607), add an unconditional reset of `.ralph/.exit_signals` to an empty-arrays JSON object. This is the primary fix: regardless of how the previous run ended, every new invocation of ralph starts with a clean exit-signal slate.

Also emit a `log_status "INFO"` message so the reset is visible in `.ralph/logs/ralph.log`.

> The existing guard in `init_call_tracking()` (`if [[ ! -f "$EXIT_SIGNALS_FILE" ]]`) only creates the file when absent; it must remain as-is for the per-loop initialisation path, but the startup reset above supersedes it for the first iteration.

---

### 2. Call `reset_session()` in the API-limit "user chose exit" path — `file:ralph_loop.sh`

At lines 1736–1739, before the `break` in the `if [[ "$user_choice" == "2" ]]` branch, add a call to `reset_session "api_limit_exit"`. This mirrors every other exit path in the loop and ensures EXIT_SIGNALS_FILE and RESPONSE_ANALYSIS_FILE are cleaned up when the user explicitly exits due to the 5-hour API limit.

```
# Before:
if [[ "$user_choice" == "2" ]]; then
    log_status "INFO" "User chose to exit. Exiting loop..."
    update_status ...
    break
fi

# After:
if [[ "$user_choice" == "2" ]]; then
    log_status "INFO" "User chose to exit. Exiting loop..."
    reset_session "api_limit_exit"          # ← add this
    update_status ...
    break
fi
```

---

### 3. Fix `Current loop: #null` display — `file:lib/circuit_breaker.sh`

**3a. Initialise `current_loop` in the state file.**  
In both `init_circuit_breaker()` (the `cat > "$CB_STATE_FILE"` heredoc, ~line 46) and `reset_circuit_breaker()` (~line 409), add `"current_loop": 0` to the JSON object. This ensures the field is always present after a fresh init or manual reset.

**3b. Use a fallback in `show_circuit_status()`.**  
At line 372, change:
```bash
local current_loop=$(echo "$state_data" | jq -r '.current_loop')
```
to:
```bash
local current_loop=$(echo "$state_data" | jq -r '.current_loop // "N/A"')
```
This prevents `#null` from appearing even against old state files that predate the fix.

---

### 4. Add a diagnostic hint to `should_exit_gracefully()` — `file:ralph_loop.sh`

At the top of `should_exit_gracefully()` (~line 494), add a `log_status "INFO"` line that logs the current contents of `done_signals` and `completion_indicators` lengths. This makes it trivial to diagnose the trigger condition from `.ralph/logs/ralph.log` in future reports without needing to reproduce the issue.

---

### Flow after the fix

```mermaid
sequenceDiagram
    participant User
    participant main() as main()
    participant ESF as .exit_signals
    participant loop as while loop
    participant exec as execute_claude_code()

    User->>main(): ralph --monitor
    main()->>ESF: reset to empty arrays (NEW)
    main()->>loop: enter while true
    loop->>loop: should_exit_gracefully()
    loop-->>exec: no stale signals → proceeds
    exec->>exec: record_loop_result() sets current_loop
```

Without the fix, the stale `done_signals` in `ESF` caused `should_exit_gracefully()` to return `"completion_signals"` immediately, breaking before `execute_claude_code()` was ever called — leaving `current_loop` as `null`.

---

Execution Information

Branch: main
Commit: 622acb5

---

💡 Tips

Supported Commands (Inside Comments)

• Use @traycerai generate to iterate on the previous version of the implementation plan.

Supported Commands (Inside Description)

• Add @traycerai ignore anywhere in the ticket description to prevent this ticket from being processed.
• Add @traycerai branch:<branch-name> anywhere in the ticket description to specify the target branch for the implementation plan.

Community

• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[PBaumfalk]

I have the same problem. Ralph ends after the first loop and it shows just 1/100 API Calls.