Escalations: work that had to be done on the host, each a bug to fix

Open
  • Is something wrong?
#59 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
12/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
github-actions, swift
Domain
ci-cd, devops, infrastructure

Research direction

This is a tracking list of host-dependent chores, not one task, so pick a single checklist item and follow its linked issue (#52, #53, #54, #55, #57 or #58) rather than the whole list. Start from the pull request or issue it names and read the code it changes, such as the runner, lease or VM-slot handling. Done means that item's ticked behaviour works from inside a container without host intervention.

Written by the indexing model from the issue text.

Description

The goal: agents run in containers and finish their work from there. Every time something had to be done outside a container (on the host, from a native session, or by the owner), that's a bug. This issue lists them with the fix for each; items are ticked as their fix lands. Items owned by other repositories are linked from here.

2026-10-31

  • Re-running or cancelling a CI run. Agents' GitHub Apps lack Actions write, and gh_mcp's policy refuses it, so a run failed by infrastructure (a stall, VM capacity) waits for the owner.
    • Fix: grant the agent apps Actions read/write; gh_mcp allows "re-run failed jobs" and "cancel" for runs in allowed repositories (no dispatch of release workflows).
    • Interim: oss's JIT runners take infrastructure retries in-server.
  • Registering a self-hosted runner per repository (sudo, an admin registration token).
    • Fix: OS Server's just-in-time runners (#52 merged, #54 open; trial passed) for every repository. Then retire the runners on the Mac.
  • Installing and restarting OS Server (a person or a helper copies the app and relaunches; no headless install).
    • Fix: OS Server updates itself from Applications Server; a scheduled restart (drain, persist the queue, restart between jobs); an API or MCP call to schedule it, open to a holder with permission.
  • Orphaned leases after a client stall or an empty answer (a lease answered, its client never told).
    • Fixes:
      • #55 (hello answered at once, clients retry) — merged, not yet installed;
      • an empty lease answer retried, with the lease found by label;
      • each answer's write logged;
      • ci leases released when their GitHub job has ended.
  • Stalls: "no oss server answered" under load.
    • #55 logs tasks waiting for a thread; fix the cause it shows.
  • Container networks broken by another network's teardown (the vmnet bridge fight); fixed by moving a session out and back in.
    • Fix: #53 (one long-lived network), plus health checks that remake a container whose network died.
  • Image builds run by hand on the host, and a build not holding its VM slot (CI over-admitted, "maximum active VMs").
    • Fix: #57 (image builds take a slot for their lifetime); an API or MCP call to build a base from a reviewed layer script.
  • Host inspection by hand: bases' sizes, leftovers, logs, hardware.
    • Fix: #58 (the host breakdown), and read-only API/MCP calls for OS Server's log and storage inventory.
  • Removing leftovers (failed builds, old bases).
    • Fix: cleanup of failed builds (#57), and an API to remove a base no lease uses.

Owned elsewhere:

  • Visor: attachments unreadable in container sessions; subagent rows left "running" after their agents ended; a crash reproduced only with the Mac app.
  • Visor: permission prompts from a container session that time out unanswered.
  • Repository settings (branch protection, CODEOWNERS merges, creating repositories, closing pull requests) stay with the owner by design; not bugs.

🤖 Generated with Claude Code

Dominant language
Swift
Stars
1
Forks
0
Avg merge
2h 30m
Merged PRs (30d)
111

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from AttilaTheFun/oss

All issues in AttilaTheFun/oss

Similar issues

More Swift issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.