⭐ Auto healing failing runs (The autonomous company)

[eonist]

action -> failure -> read log -> find fix for failure -> commit fix -> runs action

[eonist]

Issue [#340 "Auto healing failing runs"](#340) in eoncode/runner-bar is currently open with no comments yet . It was created on May 8, 2026 by [@eonist](https://github.com/eonist) .

Concept Overview

The issue describes an auto-healing CI pipeline loop with the following flow :

1. Action — a GitHub Actions workflow runs
2. Failure — the run fails
3. Read log — the failure log is parsed/analyzed
4. Find fix — a fix for the failure is identified (likely via AI or heuristics)
5. Commit fix — the fix is committed automatically
6. Re-run action — the workflow is triggered again

What This Implies

This is an ambitious self-healing automation concept — essentially a feedback loop where the CI system diagnoses and repairs itself without human intervention . Key engineering challenges to consider:

• Log parsing — reliably extracting the root cause from noisy CI logs
• Fix generation — either rule-based (known error patterns → known fixes) or AI-assisted (e.g., calling an LLM with the log)
• Safety/loop guards — preventing infinite retry loops with a max-attempt cap or a "confidence threshold" before committing
• Commit hygiene — auto-commits should be tagged/labeled clearly (e.g., [auto-fix]) to avoid polluting git history

Would you like to flesh this out into sub-issues, or start designing the implementation approach (e.g., a GitHub Actions workflow that handles this loop)?

[eonist]

Since runner-bar is a macOS menu bar app built in Swift/SwiftUI, the auto-healing feature (issue #340) would primarily interact with the existing UI surface rather than require entirely new screens. Here's how the existing UI maps to the feature:

Existing UI Already in Play

Looking at the source files in [Sources/RunnerBar/](https://github.com/eoncode/runner-bar/tree/0bfc02f3577bc33aadd4c019fcdcf1ecf66da5db/Sources/RunnerBar) , these views are directly relevant:

• [ActionDetailView.swift](https://github.com/eoncode/runner-bar/blob/0bfc02f3577bc33aadd4c019fcdcf1ecf66da5db/Sources/RunnerBar/ActionDetailView.swift) — shows a failing action; this is where a "healing in progress" indicator would live
• [JobDetailView.swift](https://github.com/eoncode/runner-bar/blob/0bfc02f3577bc33aadd4c019fcdcf1ecf66da5db/Sources/RunnerBar/JobDetailView.swift) — displays job-level status; would need to show the auto-heal cycle state
• [StepLogView.swift](https://github.com/eoncode/runner-bar/blob/0bfc02f3577bc33aadd4c019fcdcf1ecf66da5db/Sources/RunnerBar/StepLogView.swift) — renders step logs; the parsed failure reason could be highlighted here
• [ReRunButton.swift](https://github.com/eoncode/runner-bar/blob/0bfc02f3577bc33aadd4c019fcdcf1ecf66da5db/Sources/RunnerBar/ReRunButton.swift) — the re-run trigger; the auto-heal loop would programmatically invoke this after committing a fix
• [LogCopyButton.swift](https://github.com/eoncode/runner-bar/blob/0bfc02f3577bc33aadd4c019fcdcf1ecf66da5db/Sources/RunnerBar/LogCopyButton.swift) — copying logs; could be reused/extended to pipe log content into the fix-finding logic
• [PopoverMainView.swift](https://github.com/eoncode/runner-bar/blob/0bfc02f3577bc33aadd4c019fcdcf1ecf66da5db/Sources/RunnerBar/PopoverMainView.swift) — the main popover panel; a healing status badge or spinner could surface here

New UI That Would Be Needed

These are net-new surfaces the feature would likely require:

• Auto-heal status badge — a small indicator in PopoverMainView or ActionDetailView showing 🔄 Healing…, ✅ Fixed, or ❌ Max retries reached
• Heal attempt counter — displayed inline on JobDetailView to show attempt N of max (e.g. "Retry 2/3")
• Fix preview/diff view — a new sheet or expandable section showing what change was committed, so you can review the auto-fix before or after it runs
• Auto-heal toggle in [SettingsView.swift](https://github.com/eoncode/runner-bar/blob/0bfc02f3577bc33aadd4c019fcdcf1ecf66da5db/Sources/RunnerBar/SettingsView.swift) — since SettingsView.swift is already the central preferences hub, an opt-in toggle + max retry count field fits naturally there
• macOS notification — leveraging the existing [NotificationPrefsStore.swift](https://github.com/eoncode/runner-bar/blob/0bfc02f3577bc33aadd4c019fcdcf1ecf66da5db/Sources/RunnerBar/NotificationPrefsStore.swift) to fire a system notification when healing succeeds or gives up

The heaviest lift would be the fix preview sheet and wiring the heal state into ActionDetailView and ReRunButton — the rest can likely reuse existing components.

[eonist]

Here's an ASCII art layout of the auto-healing UI flow across the existing RunnerBar macOS popover:

┌─────────────────────────────────────────┐
│  🏃 RunnerBar          [●] idle  [⚙️]   │  ← StatusIcon / PopoverMainView
├─────────────────────────────────────────┤
│  repo: eoncode/runner-bar               │
│  ┌──────────────────────────────────┐   │
│  │ ❌ build.yml    #342  failed     │   │  ← ActionDetailView
│  │    🔄 Auto-healing... (2/3)      │   │  ← NEW: heal badge + attempt counter
│  │    └─ "SwiftLint rule violation" │   │  ← StepLogView (parsed failure reason)
│  │                                  │   │
│  │  [📋 Copy Log]  [▶ Re-Run]       │   │  ← LogCopyButton / ReRunButton
│  └──────────────────────────────────┘   │
│                                         │
│  ┌──────────────────────────────────┐   │
│  │ 📝 Fix committed (auto)          │   │  ← NEW: fix preview section
│  │  - removed trailing whitespace  │   │
│  │  - line 42: force_cast removed  │   │
│  │            [👁 View Diff]        │   │  ← NEW: opens diff sheet
│  └──────────────────────────────────┘   │
└─────────────────────────────────────────┘

        ↓  on success / give up

┌─────────────────────────────────────────┐
│  🔔 Notification (macOS)                │  ← NotificationPrefsStore
│  "Auto-heal succeeded: build.yml ✅"    │
│   or "Gave up after 3 attempts ❌"      │
└─────────────────────────────────────────┘

        ⚙️  Settings panel (SettingsView)

┌─────────────────────────────────────────┐
│  Auto-Healing                           │
│  ┌────────────────────────────────┐     │
│  │  Enable auto-heal   [  ON  ]   │     │  ← new toggle
│  │  Max retries         [ 3  ]    │     │  ← new stepper
│  │  Notify on fix      [  ON  ]   │     │  ← reuses NotificationPrefsStore
│  └────────────────────────────────┘     │
└─────────────────────────────────────────┘

The core loop sits entirely within ActionDetailView — the heal badge, attempt counter, and fix preview all stack below the existing job status. The ReRunButton gets called programmatically at the end of each cycle, and SettingsView gains three new controls to govern the behaviour.

[eonist]

this should be an option inprefs: creat heal branch and pr (pr is important for rerun of action etc) or heal on runner branch directly. and when branch runs green merge into runner brnach etc

[eonist]

this should be an option inprefs: creat heal branch and pr (pr is important for rerun of action etc) or heal on runner branch directly. and when branch runs green merge into runner brnach etc

Great design decision — here's how that preference maps out:

⚙️  Settings panel (SettingsView) — Auto-Healing

┌─────────────────────────────────────────────┐
│  Auto-Healing                               │
│  ┌─────────────────────────────────────┐    │
│  │  Enable auto-heal      [  ON  ]     │    │
│  │  Max retries            [ 3  ]      │    │
│  │  Notify on fix         [  ON  ]     │    │
│  │                                     │    │
│  │  Heal strategy:                     │    │
│  │   ○ Heal on runner branch directly  │    │
│  │   ● Create heal branch + PR         │    │  ← recommended default
│  │                                     │    │
│  │   PR title prefix  [auto-heal/]     │    │  ← e.g. auto-heal/fix-build-yml
│  │   Auto-merge on green  [  ON  ]     │    │  ← merges PR → runner branch
│  │   Delete heal branch   [  ON  ]     │    │  ← cleanup after merge
│  └─────────────────────────────────────┘    │
└─────────────────────────────────────────────┘

Heal Branch + PR Flow

runner-branch (e.g. main / dev)
    │
    │  [failure detected]
    ▼
auto-heal/fix-build-yml-abc123   ← new branch cut from runner branch
    │
    │  [fix committed]
    │  [PR created → targets runner branch]
    │  [PR triggers CI re-run]  ← this is the key reason for the PR
    │
    ├─ 🔴 still failing → commit another fix (up to max retries)
    │
    └─ 🟢 green → auto-merge PR → runner branch
                → delete heal branch
                → notify: "Auto-heal merged ✅"

Direct Branch Flow

runner-branch
    │
    │  [failure detected]
    │  [fix committed directly]
    │  [re-run triggered via ReRunButton API call]
    │
    ├─ 🔴 still failing → commit another fix
    └─ 🟢 green → notify: "Auto-heal succeeded ✅"

Why "Branch + PR" is the Better Default

Concern	Branch + PR	Direct
CI re-run triggered naturally	✅ push to PR branch	⚠️ manual API re-trigger
Full audit trail	✅ PR history + diff	⚠️ commits only
Easy rollback	✅ close/revert PR	❌ harder
Protects runner branch	✅ never touched until green	❌ commits land immediately
Works with branch protection rules	✅	❌ likely blocked

The PR approach also means ActionDetailView can surface a direct link to the heal PR — so you can review or override the fix before merge if auto-merge is off .

[eonist]

Maybe add a fix now button. next to failed jobs. which would open a new view. with proposal for a fix. from qwen 7b. olllama connector. then when pressing accept solution. move to commit view. with commit msg auto generated. then commit and push etc. then back to main view?

[eonist]

Maybe add this feature later.

[eonist]

Let's start with the basics. just a beta feature that lets you fix simple failures. with qwen 7b + git commit directly into branch that failed. + generic git commit msg. "runner-bar healing fix" 👈 free marketing :D

[eonist]

Instead what we can do is add a way for a run to execute something if a run fails. eigther a file for each repo in settings. or a file inside the repo. an .md doc that has instructions.

like launching terminal with log with instructions to end to end fix things. like a super prompt. or even launch pplx personal computer