Contributor summary: This is a future idea and research note about resuming agentic coding runs, not an active implementation request. Useful evidence or lessons from similar systems are welcome. (Difficulty: hard)
Personal reminder for me. I do not plan to work on this soon. This is not a request for someone else to implement it.
Agents sometimes reach Ralph's time limit with staged, unstaged, or new files left behind. The next agent or a human then has to reconstruct what happened, and the spec may be out of date.
Possible approach: keep ralph.sh unchanged. Have the Python launcher save the exact session ID, then resume that conversation after a timeout with a limited allowance to finish checks, update the spec and project status, and commit its own work. Record the outcome before starting fresh work.
Experiment results (September 11, 2026):
| Check |
Result |
| Real Ralph timeout with Copilot 1.0.71 |
Stopped after about 60 seconds with staged, unstaged, and new test files. The next iteration did not start. |
| Resume the exact Copilot conversation |
Passed: remembered a test phrase from the original conversation, committed all three files, preserved their contents, and left the test checkout clean. |
| Resume an unknown Copilot session ID |
Failed clearly; did not start a fresh conversation. |
| Worker exits normally with unfinished files |
Ralph still started the next iteration. This needs a separate check. |
| Other installed coding tools |
Codex, Claude, and Antigravity have options to resume a saved conversation. Their recovery after timeout was not tested live. Claude's current preset disables saved sessions and would need to change. |
| Cleanup |
All temporary files and test sessions removed. Repository unchanged. |
This was a small disposable test, not proof that recovery will always finish real work or pass the full gate. The remaining choices are how much extra time to allow, when to stop retrying, how to check the spec is current, and how to identify each agent's changes when several share a checkout. Recovery should finish the existing task, not start another one. Use the recorded session ID rather than the most recent session.
Rough size estimate: 100–150 lines of application code for one coding tool, or 200–350 for all four plus checking unfinished work after normal exits. Tests could add 150–250 lines. These are estimates, not measured implementation sizes. Handling several agents in one checkout would add work beyond this estimate.
How to help
Add evidence or lessons from similar systems in a comment. Please do not start a large implementation from this issue.
Contributor summary: This is a future idea and research note about resuming agentic coding runs, not an active implementation request. Useful evidence or lessons from similar systems are welcome. (Difficulty: hard)
Personal reminder for me. I do not plan to work on this soon. This is not a request for someone else to implement it.
Agents sometimes reach Ralph's time limit with staged, unstaged, or new files left behind. The next agent or a human then has to reconstruct what happened, and the spec may be out of date.
Possible approach: keep ralph.sh unchanged. Have the Python launcher save the exact session ID, then resume that conversation after a timeout with a limited allowance to finish checks, update the spec and project status, and commit its own work. Record the outcome before starting fresh work.
Experiment results (September 11, 2026):
This was a small disposable test, not proof that recovery will always finish real work or pass the full gate. The remaining choices are how much extra time to allow, when to stop retrying, how to check the spec is current, and how to identify each agent's changes when several share a checkout. Recovery should finish the existing task, not start another one. Use the recorded session ID rather than the most recent session.
Rough size estimate: 100–150 lines of application code for one coding tool, or 200–350 for all four plus checking unfinished work after normal exits. Tests could add 150–250 lines. These are estimates, not measured implementation sizes. Handling several agents in one checkout would add work beyond this estimate.
How to help
Add evidence or lessons from similar systems in a comment. Please do not start a large implementation from this issue.