iris/ai-app
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

The VM can push to gitea now

Browse Source 
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 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017xn8nHw1tw1R6PtiY1eEtw
This commit is contained in:
irisandClaude Opus 5 committed 2026-08-28 02:30:20 -04:00
1 parent 5f8a2146e6
commit 5391fe3b34
1 file changed
+8 -6
Download Patch File Download Diff File Expand all files Collapse all files
AGENTS.md
+8 -6
View File
@@ -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**, 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. so the tunnel and the real phone can never terminate here.
- **Code reaches the host through gitea, not the shared mount.** This VM's - **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 `~/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 `git@git.arirex.me:iris/ai-app`, and the `iris-ai` bot key this VM holds
for it — pushing from here fails with `Permission denied (publickey)`. is authorized to push there — it was not until 2026-08-28, so anything
The host pushes, and its own separate clone — outside the shared mount — written before that saying a push fails with `Permission denied
is what gets built and run. So the review at push time, not a filesystem (publickey)` is stale. The host still builds and runs from its own
permission, is what keeps VM-authored code off the host. 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 - 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 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 shared path, the two `cargo build`s replace each other's binary and each