Si estás usando Pi Agent como agente en tu macOS, seguro que te has encontrado un problema similar al mío: quieres seguir usando 1Password para gestionar tus credenciales SSH para acceder a tus repositorios de GitHub, y te das cuenta de que cada vez que estás dentro de una sesión de Pi, no puedes hacer commit y push a tu repositorio online porque el entorno aislado de nono.sh te lo impide. Cambias permisos y sigues igual… un infierno. No he conseguido que funcione de esta manera, pero sí usando un token de GitHub y la inyección de la credencial en el perfil de nono. Te cuento el proceso en macOS, Pi y nono.
El problema
Quería que git push funcionara desde dentro de pi, el famoso agente IA que todo el mundo está empezando a usar debido a su sencillez y poder de personalización (sandboxed con nono.sh, sandbox de macOS Seatbelt) usando 1Password como agente SSH para firmar las conexiones (algo que suelo usar habitualmente en iTerm2 o en el Terminal de macOS y funciona como la seda). El push fallaba con mensajes de error poco claros, alternando entre «parece un problema de sandbox» y «el comando tuvo éxito» sin que el push realmente se completara.
Por qué mi agente SSH de 1Password fallaba dentro de un sandbox (y cómo lo resolví cambiando a HTTPS + token)
Llevo unas semanas ejecutando mi agente de codificación pi dentro de un sandbox de macOS con nono (aislamiento a nivel de kernel, no una capa de permisos que se pueda saltar fácilmente). ¿Para qué? Si has usado la app de Claude, te habrás dado cuenta de que tienes que usar una extensión llamada FileSystem para que el agente pueda escribir en tus carpetas; esto no pasa con Pi, que puede escribir en todo tu disco duro. Por eso instala nono.sh: si algún día un agente de IA hace algo que no debería (por error, o por una inyección de prompt desde una página web que está leyendo), el sandbox limita el daño real, no solo lo advierte.
Todo funcionaba bien hasta que intenté hacer git push desde dentro del sandbox. Uso 1Password como gestor de claves SSH, lo que significa que la clave privada nunca toca el disco de mi Mac, y cada operación de firma pasa por un agente que habla con la app de 1Password vía un socket Unix.
El error que te sale en Pi
Cuando estás dentro de Pi y quieres hacer un push a GitHub, no te va a dejar si tienes Pi dentro de nono.sh. Te va a saltar un aviso de Sandbox. Y cuando sale el de Pi, te va a preguntar si quieres conceder acceso a los directorios que han sido bloqueados.
Era demasiado bonito para ser verdad: le das a aceptar, a permitir y piensas que ya va a funcionar. Ni por asomo. Vas concediendo un permiso tras otro que se guarda en tu perfil pi.json de nono y nunca consigues hacer el commit online.
- Denegación de
known_hosts(read+write): al salir depi, nono mostraba que se había bloqueado el acceso a ~/.ssh/known_hosts. Intenté añadir known_hosts a allow_file. Nada. - Error de parseo: «not a directory»: Profile path ‘/Users/…/.ssh/known_hosts’ is not a directory. Use –allow-file for single files. Había puesto la ruta en allow (que solo acepta directorios) en lugar de en allow_file. Movi la ruta… y nada.
- Intente también poner en allow_file el .1password/agent.sock. Nada.
No funcionaba nada, y cada vez me pedía meter un directorio diferente en el json de nonon para que funcionara el push. Menudo rollo.
¿Causa real del problema? Variables de entorno filtradas.
Aun con el socket accesible, el push seguía fallando. Fui revisando la documentación de inyección de credenciales de nono cuando encontré la pieza que probablemente explicaba todo desde el principio:
«Injected credentials bypass the environment.allow_vars allow-list, so they always reach the child process even when other variables are filtered.» en https://nono.sh/docs/cli/features/credential-injection
Es decir, nono filtra qué variables de entorno llegan al proceso sandboxed, por un allow-list. Si SSH_AUTH_SOCK —la variable que le dice a ssh dónde está el agente— no estaba en esa lista, daba igual cuántos permisos de filesystem le diera al socket: la variable simplemente nunca llegaba al proceso, y ssh no tenía forma de saber que el agente existía.
La decisión: dejar de pelear con SSH
Ya llevaba varias horas resolviendo este problema sin mucha esperanza de acertar, ni siquiera con la ayuda de Claude o Deppseek, los modelos de IA que suelo usar, hasta que decidi cambiar de rumbo y utilizar un Personal Access Token de GitHub: un tipo de secreto estático que el sistema de credenciales de nono está diseñado para manejar.
La solución que funcionó: HTTPS + token en lugar de SSH
Cambié de protocolo de autenticación para git, en vez de seguir intentando que el agente SSH funcionara dentro del sandbox. Los pasos, completos:
1. Token de GitHub con scope mínimo. Fine-grained personal access token, limitado a los repos concretos que necesito, con permiso Contents: Read and write y nada más.
2. Guardarlo en el Keychain de macOS, nunca en un archivo de texto ni en una variable de shell persistente (te pedira que copies el token):
security add-generic-password -s "nono" -a "github_token" -w
3. Credential helper de git que lee el token de una variable de entorno:
git config --global credential.https://github.com.helper \
'!f() { echo username=x-access-token; echo "password=$GITHUB_TOKEN"; }; f'
4. Inyección de la credencial en el perfil de nono: esta es la pieza que hace que todo funcione dentro del sandbox sin pelear con filtrado de variables (yo lo he metido en /Users/usuario/.config/nono/profiles/pi.json (creado desde https://registry.nono.sh/packages/always-further/pi):
"env_credentials": {
"github_token": "GITHUB_TOKEN"
}
5. Cambiar el remote de cada repositorio, de SSH a HTTPS desde la terminal de macOS:
git remote set-url origin https://github.com/usuario/repo.git
Probé el push. Funcionó a la primera. Sin bypass_protection, sin campos de socket, sin tocar ~/.ssh/config, sin preocuparme de qué variables de entorno llegaban filtradas y cuáles no.
Fíjate en la imagen. Después de horas de probar cosas nuevas, hasta Deepseek se puso contento de que funcionara.
¿Último problema a resolver? Para que funcione también en tu terminal normal, tienes que exportar la variable ahí también, leyéndola del mismo sitio donde la guardaste (el Keychain):
echo 'export GITHUB_TOKEN=$(security find-generic-password -s "nono" -a "github_token" -w 2>/dev/null)' >> ~/.zshrc
source ~/.zshrc
¿Qué pasa al hacer esto? El problema: cada git push dentro de pi/nono empezada a lanzar dos líneas de rror:
fatal: failed to get: -50
fatal: failed to store: -50El push funcionaba, pero… ¿Qué estaba pasando? macOS configura credential.helper = osxkeychain a nivel sistema. La sandbox de nono bloquea el llavero, por lo que daba error en cada operación. Además, $HOME no estaba definida dentro de la sandbox, así que git ni siquiera encontraba ~/.gitconfig, donde vive el helper con GITHUB_TOKEN que sí puede autenticar.
La solución era poner dos variables en el perfil de nono:
"environment": {
"allow_vars": [],
"deny_vars": [],
"set_vars": {
"HOME": "/Users/tuusuario",
"GIT_CONFIG_SYSTEM": "/dev/null"
}
},La primera devuelve a git el acceso a su config global. La segunda le dice que ignore el osxkeychain del sistema.
Conclusión
Cuando un mecanismo de credenciales (un agente, una sesión IPC, un prompt biométrico) choca con un sandbox de permisos estáticos como el de nono, la solución no siempre está en seguir añadiendo permisos hasta que encaje. A veces el mecanismo en sí es el problema. Hay que cambiarlo por uno que sí encaje con el modelo de seguridad que estás usando (un secreto estático para un sistema de inyección de credenciales pensado para secretos estáticos).
Si estás corriendo un agente de IA en un sandbox y usas 1Password (o cualquier otro gestor que mantenga las claves SSH fuera de disco) para tus operaciones de git, mi recomendación es que no pierdas el tiempo que perdí yo. Empieza directamente por HTTPS + token en GitHub. Déjate el SSH para fuera del sandbox.
