sergio/takana

`claude --dangerously-skip-permissions` moría en la caja con «cannot be used with root/sudo
privileges»: la instancia de sergio traía `root = true`, que mapea el uid del invocante a 0 ADENTRO
(qorpa.rs:1533), así que el CLI se veía a sí mismo como root. Con `root = false` queda uid 1001 y la
bandera se acepta — comprobado: `claude --dangerously-skip-permissions --version` contesta.

De paso, a esa instancia le faltaba `/store` en `rw` —la de root ya lo tenía—: sin eso el agente lee
el store y no puede sellar nada. Ahora escribe (probado y limpiado).

Y se corrige el aviso sobre los builds, que ahora falla por otro motivo: con root=false el bwrap
anidado SÍ se levanta y /proc monta, pero no puede mapear el uid 0 que takana build pide, porque
sergio no tiene rango en /etc/subuid y newuidmap/newgidmap no son setuid en esta caja. Cerrarlo es
una decisión con precio (un setuid más, y el /usr/bin de acá está hidratado del store), no un
trámite; mientras tanto el build se le pide al anfitrión por ssh.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

diff --git a/scripts/servidor/claude-caja.sh b/scripts/servidor/claude-caja.sh
index c8a860af..79934253 100755
--- a/scripts/servidor/claude-caja.sh
+++ b/scripts/servidor/claude-caja.sh
@@ -13,11 +13,28 @@
 # falta: `qorpa run` levanta la jaula con user namespaces y anda **sin privilegio**, siempre que el
 # directorio de la instancia sea del usuario.
 #
-# ⚠ LOS BUILDS NO CORREN DENTRO DE LA JAULA. `takana build` levanta su propio bwrap y ahí falla con
-# «Can't mount proc on /proc» aunque la instancia declare `nesting = true`. El camino que sí anda es
-# pedírselo al ANFITRIÓN por ssh:
+# ⚠ LOS BUILDS SIGUEN SIN CORRER DENTRO DE LA JAULA, pero el motivo cambió y conviene tenerlo
+# medido (2026-09-18). Antes, con `root = true`, el bwrap anidado ni se levantaba: «Can't mount proc
+# on /proc». Con `root = false` **sí se levanta y /proc monta** —comprobado—, y lo que ahora falla es
+# otra cosa: el anidado **no puede mapear el uid 0** que `takana build` le pide, porque `sergio` no
+# tiene rango en `/etc/subuid` (sólo lo tiene `root`) y encima `newuidmap`/`newgidmap` **no son
+# setuid** en esta caja (`-r-xr-xr-x`). Resultado: el sandbox del build correría como 1001 y el
+# `install` que escribe `/out` con dueños se cae.
+#
+# Cerrarlo del todo son dos cosas con su precio: darle rango a `sergio` en `/etc/subuid`+`subgid`, y
+# volver setuid a esos dos ayudantes —que es lo normal en cualquier distro, pero es un binario
+# setuid más y, como el `/usr/bin` de acá está HIDRATADO del store, una rehidratación lo revierte—.
+# Es decisión, no trámite.
+#
+# Mientras tanto el camino que sí anda es pedírselo al ANFITRIÓN por ssh:
 #
 #   ssh -p 22022 root@127.0.0.1 'cd /opt/takana && flock -o work/.farm-build.lock takana build <r>'
+#
+# ⚠ Y UNA JAULA QUE TE MAPEA A ROOT ROMPE AL PROPIO AGENTE: con `root = true` el CLI se ve uid 0 y
+# **rechaza `--dangerously-skip-permissions`** («cannot be used with root/sudo privileges»). Por eso
+# las instancias de PERSONA van con `root = false` (queda uid 1001 adentro) y con `/store` en `rw`,
+# que es lo que la de `root` ya tenía y a la de `sergio` le faltaba: sin eso el agente lee el store
+# y no puede sellar nada.
 set -eu
 
 _yo="$(id -un)"