Publish the agent’s results (git runs on the host)

The agent works inside an untrusted VM, so the VM never holds forge credentials and never contacts a forge — all forge git is a host operation. Code goes in via the repo sync; results come out through the host.

Why not push from the VM?

A push from the guest would need a forge credential in the guest. Even a short-lived, repo-scoped token is still a credential sitting in an assumed-compromised box — one more thing to leak. Keeping every clone/push on the trusted host removes that surface entirely. The only credential the guest ever holds is the per-VM ephemeral SSH key, which grants nothing on your forge. See The zero-trust model.

The flow

1. Code in. Local: virtiofs live-mounts your tree. Remote: ./ztd mount sshfs-syncs your working tree (incl. .git) up.

2. Agent works in the VM and makes local, credential-less commits — no remote is contacted.

3. Results out. Pull the agent’s commits back to your host checkout, then push from the host with your own credentials:

   # local backend: the .git is the same tree (virtiofs) — the commits are already here.
   # remote backend: pull them back over the ephemeral key first —
   TARGET=proxmox ./ztd fetch
   git log --oneline ztd/<branch>     # review
   git push origin <branch>           # host push, your creds, your forge

The host push uses whatever the operator already trusts — your personal auth, or (future) a per-run scoped gh/glab token minted on the host. ZTD doesn’t mint tokens; that stays your forge CLI’s job.

Future — a narrow guest exception. A gh/glab token scoped to issue creation only (never repo write/push) could be run inside the VM so the agent can file issues autonomously. That’s a deliberate, minimal exception; the clone/push path stays host-side regardless. Out of scope for v1.