Bug: set -e kills script on non-zero return from execute_claude_code — loop never retries

[chickenbeast]

Description

When execute_claude_code() returns a non-zero exit code (e.g., timeout exit code 1, or any other failure), the entire Ralph script terminates silently instead of retrying. The retry logic in the main loop is never reached.

This affects all failure modes — timeout, execution errors, etc. The loop should wait 30 seconds and retry, but instead Ralph just dies.

Root Cause

ralph_loop.sh starts with set -e (line 6), which causes the script to exit on any uncaught non-zero return.

In main(), execute_claude_code is called bare — not in a conditional context:

# Line ~1702
execute_claude_code "$loop_count"
local exec_result=$?

With set -e active, when execute_claude_code returns 1 (timeout) or any non-zero code, bash terminates the script immediately. The local exec_result=$? on the next line is never reached, and the retry logic in the if/elif/else block below it never fires.

Expected Behavior

On timeout or execution failure, Ralph should:

1. Log "Execution failed, waiting 30 seconds before retry..."
2. Sleep 30 seconds
3. Continue to the next loop iteration

This is exactly what the existing code at the else branch (line ~1755) is designed to do — but it's unreachable.

Actual Behavior

Ralph exits silently after the first non-zero return from execute_claude_code. The log ends abruptly with no retry message, no "Loop #2" entry.

Example log output:

[WARN] Claude Code execution timed out after N minutes
[WARN] ⏱️ Claude Code execution timed out (not an API limit)
<EOF — script died>

Fix

Use the standard bash idiom for safely capturing exit codes under set -e:

         # Execute Claude Code
-        execute_claude_code "$loop_count"
-        local exec_result=$?
+        # Use || to capture exit code safely under set -e
+        local exec_result=0
+        execute_claude_code "$loop_count" || exec_result=$?

The || puts the function call in a conditional context, preventing set -e from firing. exec_result captures the actual exit code (0, 1, 2, or 3) so the existing if/elif/else dispatch works correctly.

Affected Versions

Tested on v0.11.5 (commit 622acb5). Likely affects all versions since set -e was added.

Related

Possibly related to #194 — some users reporting "ralph ends early" after one loop may be hitting this bug rather than the stale exit signals issue.

[coderabbitai]

🔗 Related PRs

#90 - fix(loop): respect Claude's EXIT_SIGNAL when checking completion indicators [merged]
#179 - fix(loop): prevent silent script death on Claude timeout [merged]
#184 - fix(loop): prevent timeout from being misidentified as API 5-hour limit [merged]
#191 - feat(loop): validate Claude Code CLI command at startup (#97) [merged]
#197 - fix(loop): persist API call counter immediately, not only on success [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]

Triage: Bug 🐛

This is a valid bug report. The issue has been labeled bug and assigned to @frankbria.

Summary

set -e at the top of ralph_loop.sh causes the script to exit silently when execute_claude_code() returns any non-zero exit code. Because the function is called without a conditional context, bash's errexit fires before local exec_result=$? can capture the value — meaning the retry/error-handling logic is never reached.

Proposed Fix

The reporter provides a clean fix using the standard || idiom to place the call in a conditional context:

local exec_result=0
execute_claude_code "$loop_count" || exec_result=$?

This prevents set -e from triggering while still correctly capturing the exit code for the existing if/elif/else dispatch block.

Recommended Next Steps

1. Apply the one-line fix in ralph_loop.sh at the execute_claude_code call site.
2. Add a regression test to test_cli_modern.bats (or a new test file) verifying that a non-zero return from execute_claude_code triggers the retry path rather than script termination.
3. Consider auditing other bare function calls in main() for the same pattern.

The related issue #194 ("ralph ends early") may have some overlap — users hitting this bug could be misattributed to the stale exit signals problem.

Generated by Issue Triage Assistant for issue #200

[traycerai]

Plan

Observations

In file:ralph_loop.sh, set -e is declared on line 10. Inside main(), execute_claude_code is called bare on line 1703, followed by local exec_result=$? on line 1704. Because set -e is active, any non-zero return from execute_claude_code (exit codes 1 = timeout, 2 = API limit, 3 = circuit breaker) causes bash to terminate the script immediately — before exec_result is ever captured and before the if/elif/else retry dispatch (lines 1706–1761) is reached. There is only one call site for execute_claude_code.

Approach

Apply the minimal, idiomatic bash fix at the single call site: initialise exec_result to 0 before the call, then use || to put the function in a conditional context, which suppresses set -e while still capturing the real exit code. This is the same pattern already used elsewhere in the script (e.g., log_session_transition ... || true on line 882).

Implementation Steps

1. Fix the call site in main() — file:ralph_loop.sh lines 1703–1704

Replace the two-line bare call:

execute_claude_code "$loop_count"
local exec_result=$?

with the safe idiom:

local exec_result=0
execute_claude_code "$loop_count" || exec_result=$?

Why both lines matter:

• Declaring local exec_result=0 before the call avoids the well-known bash pitfall where local itself is a command that always returns 0, which would silently overwrite $? if written as local exec_result=$?.
• The || exec_result=$? puts execute_claude_code in a conditional context, preventing set -e from firing on a non-zero return while still routing the real exit code (1, 2, or 3) into exec_result for the existing if/elif/else dispatch below.

2. Add an explanatory comment above the call

Directly above the local exec_result=0 line, add a comment referencing the issue (e.g., # Use || idiom to capture exit code safely under set -e (Issue #200)) so future readers understand why the pattern deviates from a plain assignment.

No other files require changes. The existing if/elif/else dispatch logic and all retry/sleep/break paths remain untouched.

Import In IDE

🤖 Prompt for AI Agents

## Observations

In `file:ralph_loop.sh`, `set -e` is declared on **line 10**. Inside `main()`, `execute_claude_code` is called bare on **line 1703**, followed by `local exec_result=$?` on **line 1704**. Because `set -e` is active, any non-zero return from `execute_claude_code` (exit codes 1 = timeout, 2 = API limit, 3 = circuit breaker) causes bash to terminate the script immediately — before `exec_result` is ever captured and before the `if/elif/else` retry dispatch (lines 1706–1761) is reached. There is only one call site for `execute_claude_code`.

## Approach

Apply the minimal, idiomatic bash fix at the single call site: initialise `exec_result` to `0` before the call, then use `||` to put the function in a conditional context, which suppresses `set -e` while still capturing the real exit code. This is the same pattern already used elsewhere in the script (e.g., `log_session_transition ... || true` on line 882).

## Implementation Steps

### 1. Fix the call site in `main()` — `file:ralph_loop.sh` lines 1703–1704

Replace the two-line bare call:

```
execute_claude_code "$loop_count"
local exec_result=$?
```

with the safe idiom:

```
local exec_result=0
execute_claude_code "$loop_count" || exec_result=$?
```

**Why both lines matter:**
- Declaring `local exec_result=0` _before_ the call avoids the well-known bash pitfall where `local` itself is a command that always returns 0, which would silently overwrite `$?` if written as `local exec_result=$?`.
- The `|| exec_result=$?` puts `execute_claude_code` in a conditional context, preventing `set -e` from firing on a non-zero return while still routing the real exit code (1, 2, or 3) into `exec_result` for the existing `if/elif/else` dispatch below.

### 2. Add an explanatory comment above the call

Directly above the `local exec_result=0` line, add a comment referencing the issue (e.g., `# Use || idiom to capture exit code safely under set -e (Issue #200)`) so future readers understand why the pattern deviates from a plain assignment.

No other files require changes. The existing `if/elif/else` dispatch logic and all retry/sleep/break paths remain untouched.

---

Execution Information

Branch: main
Commit: 6ff27b4

---

💡 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.