From 5391fe3b34e7b33a588d0249e6eca8e187c5aed3 Mon Sep 17 00:00:00 2001 From: iris <2+iris@noreply.localhost> Date: Fri, 28 Aug 2026 02:30:20 -0400 Subject: [PATCH] The VM can push to gitea now The note saying otherwise predates the iris-ai bot account being authorized for this repository, and a stale "you cannot do this" is worse than no note at all -- it sends the next reader looking for a workaround that isn't needed. The checkout's path had drifted in the same sentence: it is ~/repos/ai-app, not ~/host/repos/ai-app. What the correction does not change is the posture. The host builds and runs from its own clone outside the shared mount, so a deliberate pull there is still what stands between this VM and the host -- it just isn't a push permission doing that job any more. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_017xn8nHw1tw1R6PtiY1eEtw --- AGENTS.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 9abb4f6..c3feb41 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -98,13 +98,15 @@ Established 2026-08-25, and it decides more than it looks like: 10.0.2.2, but **nothing outside can initiate a connection into the VM**, so the tunnel and the real phone can never terminate here. - **Code reaches the host through gitea, not the shared mount.** This VM's - checkout (`~/host/repos/ai-app`, a virtiofs mount the host also sees at + checkout (`~/repos/ai-app`, a virtiofs mount the host also sees at `~/stuff/vm/ai/repos/ai-app`) is a working copy only: its `origin` is - `git@git.arirex.me:iris/ai-app`, and the VM's key is **not** authorized - for it — pushing from here fails with `Permission denied (publickey)`. - The host pushes, and its own separate clone — outside the shared mount — - is what gets built and run. So the review at push time, not a filesystem - permission, is what keeps VM-authored code off the host. + `git@git.arirex.me:iris/ai-app`, and the `iris-ai` bot key this VM holds + is authorized to push there — it was not until 2026-08-28, so anything + written before that saying a push fails with `Permission denied + (publickey)` is stale. The host still builds and runs from its own + separate clone outside the shared mount, so what keeps VM-authored code + off the host is the pull being a deliberate act there, not a filesystem + permission and no longer a push this VM cannot make. - Consequence for building here: `server/target/` is shared with the host's view of *this* checkout, so if anything on the host ever builds from the shared path, the two `cargo build`s replace each other's binary and each