con / con/yolo

Remote podman connection: workspace mount fails with raw statfs error; no way to use a client-side project

Open
#76 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Shell
Stars
14
Forks
7
Avg merge
3h 7m
Merged PRs (30d)
3

Description

With a remote engine (`CONTAINER_CONNECTION`/`CONTAINER_HOST`), podman resolves
yolo's `-v` sources on the **engine host**, while yolo expands `$HOME`/`$PWD` on
the client:

```console
~/test $ CONTAINER_CONNECTION=claude yolo
Error: statfs /home/admin/test: no such file or directory # exit 125
```

- project missing on the engine → raw statfs error, no hint about the client/engine split
- path present but empty → **silently empty workspace**
- `~/.claude` / `~/.gitconfig` missing there → same failure class

Setup: rootless podman on a VM via `ssh://` connection; client host has no root
and no working local engine.

Possible fixes:

1. **Preflight (small fix):** when remote env vars are set, verify the workspace
source via a throwaway container, fail with an explanatory message ("bind-mount
sources resolve on the remote engine; sync `$PWD` there"), warn if empty, and
auto-create `~/.claude` / `~/.gitconfig` on the engine.

2. **Opt-in `--fuse-workspace` (feature):** live-serve the client's `$PWD` into the
container over the podman connection itself — `sshfs -f -o slave` inside the
container (`--device /dev/fuse --cap-add SYS_ADMIN`, sshfs added to the image),
fed by a local `sftp-server` through `podman exec -i` (fifo+pipe bridge).
Rootless end-to-end, no sshd/ports on the client, mount lifetime = container,
mounted at the original `$PWD` so session resume keeps working. Working
prototype exists; happy to submit it as a PR with a SPEC.md-style writeup.

Why not the obvious alternatives: podman client-side bind mounts are a still-open
upstream request (containers/podman#8016); `volume export/import` is unsupported
by podman-remote; kernel 9p/NFS mounts on the VM need root.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reproducing the documented remote setup with CONTAINER_CONNECTION or CONTAINER_HOST and a client-side project, then trace yolo's -v source handling. Compare the proposed preflight and --fuse-workspace approaches, including missing or empty workspace and dotfile cases. Done should provide an agreed implementation with clear remote/client error behavior and documented validation.

Written by the indexing model from the issue text.

Assessment

Tech stack
shell
Domain
devops, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.