Escalations: work a container session had to hand to the host, each a bug to fix

Open
#164 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
Needs clarification
Activity status
Active
Tech stack
swift
Domain
devops

Research direction

This is a tracking list of separate bugs, not one task, and several items depend on other open issues (#150, #158, #156). Pick a single checkbox and start from the code it names: closeSubagent for stuck subagent rows, GET /api/file for attachment access, or visor machine lease for the --help bug. Each item is done when its fix lands and its box is ticked, so confirm the scope with the maintainer before starting.

Written by the indexing model from the issue text.

Description

The goal: sessions run in containers and finish their work from there, so a native session is rarely needed. Every time something had to be done outside a container (on the host, by a native helper session, or by the owner), that's a bug. This issue lists Visor's, each with its fix; items are ticked as their fix lands. OS Server's are in AttilaTheFun/oss#59.

2026-10-31

  • Attachments unreadable in container sessions. The server saves an attached image in its own data folder on the host, and the agent is given that path. The container sees only the session's folder, so the agent can't open it. Interim: the agent fetches the file over the server's GET /api/file.
    • Fix: co-tenancy (#150, #158), where the server runs in the container beside its agents. Until then, mount the attachments folder read-only into session containers at the same path.
  • Subagent rows left "running" after their agents ended. A native session had to close them (closeSubagent).
    • Fix: when a session's agent ends or its file says a subagent finished, the server closes the subagent rows still running. Needs a reproduction first: which agent, and whether the row's end was ever written.
  • Permission prompts from a container session time out unanswered. A prompt waited 30 minutes, then the tool call failed.
    • Fix: find where the prompt stopped: whether it reached the clients as a pending approval, and whether it was pushed. A container session's prompts should reach clients exactly like a native session's.
  • The image builder and session containers losing DNS. Each time the image builder or a session's container was made again, the containers' network moved to another subnet, and whichever was older lost DNS. A native helper restarted the builder and took the session out of its container and back in.
    • Fix: one long-lived network for the builder and every session container, owned by one process (#150's network owner); a container whose network has died is detected and made again with its volumes kept (#158).
  • A crash reproduced only in the Mac app, its report on the host. The crash report was in the host's temporary folder, which the container can't see; a native helper copied it into the session's folder.
    • Fixes: reproduce Mac app bugs in a leased macOS VM, whose reports are read over SSH (done for the transcript alignment bug with tools/mac_screenshots); and a read-only server call for the host's crash reports of Visor's own apps.
  • Installing a Visor Server build on a Mac needed a native helper.
    • Fix: the Runner upgrades the servers it runs from their desired state (#158's upgrade mark), from a build on the release server.
  • Mac-only tests. macOS swift_test binaries don't link with the cross toolchain, so Mac test suites needed a whole VM.
    • Fix: #156 (the suites as macos_unit_test bundles, which link on Linux), run in a light slot on OS Server's shared macOS VM (xctest) once visor machine has that verb.
  • visor machine lease <platform> --help started a lease (waiting for a free VM) instead of printing the usage.
    • Fix: --help anywhere prints the usage, and an unknown flag is refused rather than ignored.

Owned elsewhere:

  • Re-running or cancelling a CI run from a container: the agents' GitHub Apps and gh_mcp's policy (AttilaTheFun/oss#59).

🤖 Generated with Claude Code

Dominant language
Swift
Stars
1
Forks
0
Avg merge
7h 43m
Merged PRs (30d)
131

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/visor

All issues in AttilaTheFun/visor

Similar issues

More Swift issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.