Tu primer workspace remoto de Orca en una VM de nivel gratuito con Infisical

Ejecutar cuatro agentes de código en worktrees locales de git se siente genial, hasta que cuatro servidores de lenguaje y cuatro ejecuciones de pnpm test consumen 16 GB de RAM de tu laptop. Mover tu workspace a una VM Linux de nivel gratuito acaba con el ruido del ventilador, pero enseguida aparecen dos problemas. Primero, las VM de nivel gratuito con 1 GB se quedan sin memoria incluso al compilar módulos nativos para terminales o ejecutar builds en paralelo [INFERENCE]. Segundo, copiar archivos .env a cada worktree nuevo dispersa credenciales en texto plano por un disco remoto donde los agentes se ejecutan sin solicitar permisos de forma predeterminada.

El 2 de noviembre de 2026, revisamos la documentación y el repositorio de código de Orca (stablyai/orca), la documentación de la CLI y Agent Proxy de Infisical y las reglas vigentes de los niveles gratuitos de Oracle Cloud, AWS, Google Cloud y GitHub Codespaces. Si eres ingeniero o arquitecto y estás configurando un workspace remoto para agentes, esta guía te ayudará a elegir una VM de nivel gratuito que no se quede sin memoria, configurar orca.yaml y reemplazar la copia de archivos .env por Machine Identities de Infisical y aislamiento con bubblewrap en Linux. Para conocer más sobre rotación de secretos y certificados raíz de confianza en macOS, consulta Mantén los secretos fuera del agente. Para flotas cloud con múltiples repositorios, consulta Ejecutar workspaces agénticos en la nube a escala.

TL;DR

• Elige la VM de nivel gratuito adecuada: Al 2 de noviembre de 2026, VM.Standard.A1.Flex (aarch64) de Always Free de Oracle Cloud ofrece hasta 2 OCPU y 12 GB de RAM de forma continua (1,500 horas de OCPU y 9,000 horas de GB al mes), además de 200 GB de almacenamiento en bloques. Oracle redujo a la mitad ese límite, que era de 4 OCPU / 24 GB de RAM, el 15 de junio de 2026, y las instancias antiguas de 4/24 no pueden recrearse por encima de 2/12 si se eliminan. Incluso con 12 GB, es el único nivel de costo cero y disponibilidad continua de esta lista que ejecuta worktrees en paralelo sin uso excesivo de swap [INFERENCE].
• Entiende cómo Orca crea worktrees remotos: Orca ofrece un modo SSH Target (Settings → SSH) y un modo Remote Orca Server (orca-ide serve). A noviembre de 2026, los worktrees creados por orca-ide serve en la VM aplican worktree.sharedDirectories y .worktreeinclude. Los worktrees de SSH Target omiten ambos y dependen de scripts.setup en orca.yaml.
• No copies .env entre worktrees: Orca inicia los agentes de código con flags que omiten los permisos de forma predeterminada. Los worktrees de git aíslan archivos, no procesos ni credenciales. Incluir .env en .worktreeinclude o copiarlo en scripts.setup expone los secretos sin protección a cada sesión de agente [INFERENCE].
• Separa las ejecuciones de pruebas de las sesiones de los agentes: Autentica la VM con una Machine Identity de Infisical limitada a dev (universal-auth, aws-iam o gcp-id-token). Ejecuta las pruebas puntuales de la aplicación con infisical sm run en otra pestaña de terminal después de revisar los diffs. Inicia los agentes de código dentro de infisical sm agent-proxy run para que bubblewrap (bwrap) bloquee el acceso directo a la red y adjunte las credenciales HTTP(S) durante el tránsito.

1. Cómo elegir una VM de nivel gratuito que no se quede sin memoria

Una CLI de agente de código como Claude Code o Codex envía las solicitudes de inferencia por la red, así que no necesita GPU. Los verdaderos cuellos de botella son la memoria y la E/S de disco. Una VM remota debe compilar módulos nativos para terminales en la primera conexión, mantener varios worktrees de git en disco y ejecutar administradores de paquetes o pruebas en paralelo [INFERENCE].

Los proveedores cloud modificaron varios niveles gratuitos entre julio de 2025 y junio de 2026. Verificamos cada cuota de la siguiente tabla en la documentación oficial de los proveedores el 2 de noviembre de 2026, aunque pueden cambiarlas sin previo aviso.

Antes de crear una instancia Arm de Oracle, consulta Governance → Limits, Quotas and Usage en la consola de OCI para verificar el límite de VM.Standard.A1.Flex de tu tenancy (Recursos Always Free de Oracle Cloud, consultado el 2026-11-02). Ten en cuenta dos particularidades de OCI:

• Capacidad frente a Pay As You Go: Las tenancies de Free Tier suelen encontrar errores Out of host capacity en las configuraciones Arm A1. Actualizar a Pay As You Go (PAYG) da acceso a grupos de capacidad estándar y cuesta $0 USD si te mantienes dentro de los límites de Always Free [INFERENCE].
• La regla de inactividad de 7 días: En una VM Arm de 12 GB, el 20% de memoria equivale a ~2.4 GB. Si el P95 de CPU, red y memoria de la VM se mantiene por debajo del 20% durante 7 días, Oracle puede detener la instancia. El volumen de arranque permanece intacto para que puedas iniciarla de nuevo más adelante.

2. Dos formas de conectar Orca a tu VM Linux

Orca admite cuatro modos de ejecución: checkouts locales, SSH Targets, Remote Orca Servers y un modo experimental de Cloud VM por workspace (environmentRecipes en orca.yaml, marcado como experimental a noviembre de 2026) (Formas de ejecutar Orca, consultado el 2026-11-02). Para una sola VM de nivel gratuito, usarás un SSH Target o un Remote Orca Server.

¿Qué modo debes elegir? Elige el Modo B (orca-ide serve) en una VM Arm de OCI con 12 GB siempre activa. Obtienes enlaces simbólicos automáticos para worktree.sharedDirectories, límites de memoria de systemd por terminal y sesiones que sobreviven a la suspensión de la laptop [INFERENCE]. Elige el Modo A (SSH Target) en una VM de 1–2 GB o si no quieres usar Tailscale. En el Modo A, tu laptop ejecuta el runtime de escritorio, que consume más recursos, mientras que la VM solo ejecuta el daemon ~/.orca-remote/ [INFERENCE].

Presta especial atención a la fila de .worktreeinclude en la tabla anterior. A noviembre de 2026, .worktreeinclude (PR #9791) y worktree.sharedDirectories (PR #10459) solo se ejecutan durante la creación de worktrees locales (Referencia de orca.yaml, consultada el 2026-11-02). Con orca-ide serve, los worktrees son locales para el runtime de la VM, así que ambas funciones funcionan sin configuración adicional [INFERENCE]. En el modo SSH Target, la creación remota de worktrees omite ambas y depende de scripts.setup.

Preparación de la VM Linux para ambos modos

Instala los paquetes que necesitan Orca y el sandbox de Infisical en Ubuntu 22.04 o 24.04 (x86_64 o aarch64):

sudo apt-get update && sudo apt-get install -y \
  build-essential python3 git curl jq file xvfb zlib1g-dev bubblewrap

Estos son los motivos por los que necesitas cada grupo de paquetes:

• build-essential (make, g++) y python3: Son necesarios para el modo SSH Target. En la primera conexión, Orca instala orcad en ~/.orca-remote/ y compila el módulo nativo node-pty (Worktrees por SSH, consultado el 2026-11-02). Sin ellos, Git y la edición de archivos funcionan, pero las terminales remotas no se abren. En una VM de 1 GB (e2-micro), agrega primero un archivo swap de 2 GB para que g++ no se quede sin memoria [INFERENCE].
• bubblewrap (bwrap): infisical sm agent-proxy run lo necesita en Linux para aislar los agentes de código en un sandbox (Agent Proxy local de Infisical, consultado el 2026-11-02).
• file, jq, xvfb, zlib1g-dev: Son necesarios para el modo de servidor Linux sin interfaz gráfica (Referencia del servidor Linux sin interfaz gráfica, consultada el 2026-11-02). En Ubuntu o Debian, instalar la versión .deb (sudo apt install ./orca-ide_<version>_arm64.deb) incorpora las bibliotecas compartidas restantes y agrega /usr/bin/orca-ide a PATH.

Ejecución del Modo B: orca-ide serve con límites de memoria por terminal

En Linux, Orca llama orca-ide a su binario de CLI porque /usr/bin/orca pertenece al lector de pantalla de GNOME (Instalar Orca, consultado el 2026-11-02). Dentro de una terminal de Orca, Orca agrega un shim orca a PATH, y orca-ide serve escribe ~/.local/bin/orca al iniciarse.

Para evitar que un build descontrolado congele toda la VM, habilita linger para el usuario de systemd y configura ORCA_TERMINAL_MEMORY_MAX (mínimo 256M) y ORCA_TERMINAL_MEMORY_SWAP_MAX (0 desactiva el swap) antes de iniciar orca-ide serve. Con systemd y cgroup v2 activos, Orca aísla cada terminal en un scope de usuario transitorio para que el OOM killer de Linux solo termine el proceso de esa terminal (Servidores remotos de Orca y Issue #28320, consultados el 2026-11-02):

sudo loginctl enable-linger "$USER"
export ORCA_TERMINAL_MEMORY_MAX=3G
export ORCA_TERMINAL_MEMORY_SWAP_MAX=1G
orca-ide serve --port 6768 --pairing-address 100.64.1.20

Orca lee ORCA_TERMINAL_MEMORY_MAX cuando su host de terminales (orcad) se inicia por primera vez. Nunca pases 0.0.0.0 o 127.0.0.1 a --pairing-address: Orca rechaza los comodines y los clientes remotos no pueden acceder a 127.0.0.1. Como --pairing-address solo establece la IP dentro del enlace orca://pair?code=... y no restringe la dirección de escucha del socket, bloquea el tráfico público entrante al puerto TCP 6768 en el firewall de tu proveedor cloud y en ufw. Permite el tráfico solo a través de tailscale0.

Los clientes remotos deshabilitan el botón Add account de la interfaz. Registra tus agentes de código en la VM mediante autenticación de dispositivo para completar el inicio de sesión en el navegador de tu laptop (Servidores remotos de Orca, consultado el 2026-11-02):

orca-ide account add --agent claude
orca-ide account add --agent codex

3. Por qué .worktreeinclude y los archivos .env entran en conflicto en VM remotas

Orca asigna a cada tarea su propio worktree y rama de git para que los agentes paralelos no sobrescriban los archivos de los demás (Worktrees, consultado el 2026-11-02). Como git worktree add omite los archivos ignorados por git, Orca ofrece dos mecanismos:

1. worktree.sharedDirectories en orca.yaml: Crea enlaces simbólicos desde hasta 100 directorios ignorados por git (como node_modules) del checkout principal hacia cada worktree nuevo.
2. .worktreeinclude en la raíz del repositorio: Copia rutas literales de archivos ignorados por git (hasta 1,000 líneas de rutas, con un límite de 2 GiB y 50,000 entradas del sistema de archivos por worktree; Orca omite los patrones glob con * y ?) a cada worktree nuevo (Referencia de orca.yaml, consultada el 2026-11-02).

En ¿Qué es un ADE?, mostramos el patrón local básico en el que .worktreeinclude copia .env a cada worktree. En una VM remota que ejecuta agentes autónomos, ese patrón se convierte en un problema de seguridad:

• Los agentes se ejecutan sin solicitar permisos: Como se señala en la documentación de Orca (docs/site/content/docs/agents/supported.mdx) y en la discusión de GitHub #29584 (publicada el 16 de octubre de 2026), Orca inicia los agentes de código con flags que omiten los permisos de forma predeterminada (--dangerously-skip-permissions, --dangerously-bypass-approvals-and-sandbox o --yolo). Los worktrees de git son checkouts aislados, no sandboxes de seguridad.
• Proliferación de archivos .env en texto plano: Incluir .env en .worktreeinclude (o copiar $ORCA_ROOT_PATH/.env en scripts.setup) escribe URL de bases de datos y claves de API en texto plano en el directorio de cada worktree [INFERENCE].

4. Cómo integrar Infisical en tu workspace remoto de Orca

En lugar de guardar archivos .env en disco, autentica la VM en Infisical con una Machine Identity limitada a dev (nunca a prod; para leases y rotación en producción, consulta Diseña para la filtración). Luego, separa la forma de proporcionar secretos según la carga de trabajo:

• Las ejecuciones puntuales de pruebas y builds necesitan variables reales en memoria (DATABASE_URL, REDIS_URL). Ejecútalas con infisical sm run en otra pestaña de Orca después de revisar el diff del agente.
• Los agentes de código (claude, codex) nunca deben tener claves de terceros sin protección en su entorno o sistema de archivos. Ejecútalos dentro de infisical sm agent-proxy run, que aísla al agente con bubblewrap (bwrap) y adjunta las credenciales HTTP(S) durante el tránsito.

flowchart TB
  subgraph VM["VM Linux de nivel gratuito (Ubuntu 24.04 + worktree de Orca)"]
    MI["Autenticación de Machine Identity<br/>(Universal Auth / AWS IAM / GCP ID Token)"]
    
    subgraph Tab2["Pestaña 2 de Orca: pruebas (fuera de bwrap)"]
      SM["infisical sm run"] --> DEV["pnpm test<br/>(Variables de dev en memoria; sin .env en disco)"]
    end

    subgraph Tab1["Pestaña 1 de Orca: agente de código"]
      PROXY["Agent Proxy local de Infisical<br/>(CA raíz en memoria + proxy.sock)"]
      subgraph BWRAP["Sandbox de bubblewrap (namespace de red vacío)"]
        AGENT["claude / codex<br/>Solo marcadores; ~/.ssh y ~/.infisical ocultos"]
      end
      AGENT -- "HTTP_PROXY (127.0.0.1:17321 -> proxy.sock)" --> PROXY
    end

    MI --> SM
    MI --> PROXY
  end

  INF["API de Infisical (ámbito dev)"] -- "Obtiene secretos de /app" --> SM
  INF -- "Obtiene secretos de /coding-agent" --> PROXY
  PROXY -- "Adjunta el header real" --> UP["GitHub / API HTTP(S) de destino"]

Paso 1: Instala la CLI de Infisical (>= 0.44.8) y autentica la VM

Instala la CLI de Infisical en la VM y comprueba su versión. Infisical agregó el namespace infisical sm y .infisical.yaml en la versión 0.43.145 de la CLI. Se requiere la versión 0.44.8 o posterior para usar environment, secret-path y overrides.git-branch en .infisical.yaml (Referencia de la CLI de Infisical y configuración del proyecto, consultadas el 2026-11-02).

En una VM sin interfaz gráfica, evita los inicios de sesión interactivos de usuario (infisical login), que recurren a una bóveda cifrada en el archivo ~/infisical-keyring con una frase de contraseña en ~/.infisical/infisical-config.json. Usa una Machine Identity en su lugar (Referencia de inicio de sesión de la CLI de Infisical, consultada el 2026-11-02).

En Oracle Cloud, usa Universal Auth con la CLI: a noviembre de 2026, OCI Auth de Infisical es un método de API/SDK, no un flag integrado de infisical login --method. Guarda el secreto de cliente de Universal Auth en ~/.infisical/client-secret con permisos 0700/0600. Esa ruta importa: infisical sm agent-proxy run oculta ~/.infisical dentro de bubblewrap, mientras que ~/.config/infisical/ sigue siendo legible dentro del sandbox [INFERENCE].

Como infisical sm agent-proxy run no renueva INFISICAL_TOKEN durante la sesión, genera un token nuevo directamente al iniciar los comandos para que las sesiones prolongadas de Orca nunca usen un token vencido:

infisical --version  # Verify >= 0.44.8
install -d -m 0700 ~/.infisical && chmod 0600 ~/.infisical/client-secret

# Option 1: Oracle Cloud (OCI) or any Linux VM via Universal Auth
export INFISICAL_UNIVERSAL_AUTH_CLIENT_ID="<client-id>"
INFISICAL_UNIVERSAL_AUTH_CLIENT_SECRET="$(cat ~/.infisical/client-secret)" \
  infisical login --method=universal-auth --silent --plain

# Option 2: AWS EC2 VM with an attached IAM Role (no static secret on disk)
infisical login --method=aws-iam --machine-identity-id="<identity-id>" --silent --plain

# Option 3: Google Cloud e2-micro with an attached Service Account
infisical login --method=gcp-id-token --machine-identity-id="<identity-id>" --silent --plain

Paso 2: Haz commit de .infisical.yaml y orca.yaml

.infisical.yaml contiene únicamente el ID de tu proyecto y el mapeo de rutas. Haz commit de este archivo en Git para que cada worktree lo reciba sin necesidad de .worktreeinclude:

# .infisical.yaml (requires Infisical CLI >= 0.44.8)
version: 1
secrets-management:
  project-id: "00000000-0000-0000-0000-000000000000"
  environment: "dev"
  secret-path: "/coding-agent"

Ten en cuenta una regla de la CLI: cuando se autentican como Machine Identity, infisical sm run, sm export y sm secrets ignoran project-id en .infisical.yaml y requieren --projectId o INFISICAL_PROJECT_ID (Configuración del proyecto de Infisical, consultada el 2026-11-02). En cambio, infisical sm agent-proxy run y connect sí leen project-id de .infisical.yaml. Exportar INFISICAL_PROJECT_ID en tu perfil de shell satisface ambos requisitos.

Después, agrega orca.yaml en la raíz del repositorio. Sigue dos reglas de la referencia de orca.yaml para defaultTabs:

1. Reserva la primera pestaña para el agente: En la interfaz de creación de Orca para escritorio, elegir un agente sobrescribe el comando de la primera pestaña de la plantilla. Coloca las pestañas de pruebas o auxiliares después.
2. Usa colores hexadecimales y evita los procesos sm run que observan cambios en archivos: color requiere #RGB o #RRGGBB (Orca ignora nombres de colores como "blue"). Además, no ejecutes un servidor de desarrollo que observe cambios en archivos (pnpm dev) bajo infisical sm run fuera de bwrap mientras un agente edita el mismo worktree. Cualquier código que escriba el agente se ejecutaría inmediatamente dentro del proceso sm run sin aislamiento [INFERENCE]. Ejecuta las pruebas bajo demanda después de revisar el diff y limita /app a credenciales de desarrollo desechables:

# orca.yaml
setupAgentStartupPolicy: wait-for-setup

worktree:
  sharedDirectories:
    - node_modules
    - .next/cache

scripts:
  setup: |
    set -euo pipefail
    if [ -d "$ORCA_ROOT_PATH/node_modules" ] && [ ! -e "$ORCA_WORKTREE_PATH/node_modules" ]; then
      ln -s "$ORCA_ROOT_PATH/node_modules" "$ORCA_WORKTREE_PATH/node_modules"
    fi

defaultTabs:
  - title: "agent"
    color: "#10b981"
  - title: "test-runner"
    command: "echo 'Run after diff review: infisical sm run --projectId=$INFISICAL_PROJECT_ID --env=dev --path=/app -- pnpm test'"
    color: "#3b82f6"

Elimina .env y .env.local de .worktreeinclude. Conserva allí solo archivos que no contengan secretos, como .vscode/settings.json.

Paso 3: Inicia los agentes de código dentro del sandbox bubblewrap de Linux

En la pestaña del agente del worktree, genera un token nuevo e inicia el agente dentro de infisical sm agent-proxy run (Agent Proxy local de Infisical, consultado el 2026-11-02):

INFISICAL_TOKEN="$(INFISICAL_UNIVERSAL_AUTH_CLIENT_SECRET="$(cat ~/.infisical/client-secret)" \
  infisical login --method=universal-auth --silent --plain)" \
  infisical sm agent-proxy run --env=dev --path=/coding-agent -- claude

En Linux, infisical sm agent-proxy run restringe al agente de cinco maneras:

1. Namespace de red vacío mediante bubblewrap (bwrap): bwrap crea un namespace de red aislado sin interfaz externa y bloquea DNS. Cualquier herramienta que ignore HTTP_PROXY/HTTPS_PROXY falla inmediatamente (Could not resolve host) en lugar de eludir el proxy.
2. Puente TCP de loopback hacia proxy.sock: Dentro del sandbox, un supervisor escucha en 127.0.0.1:17321 (HTTP_PROXY/HTTPS_PROXY) y reenvía el tráfico al proxy del host mediante un socket Unix (proxy.sock) en un directorio temporal con permisos 0700 (/tmp/infisical-agent-proxy-run-XXXXXX/).
3. CA raíz efímera en memoria: En macOS, Infisical escribe la CA en ~/.infisical/agent-proxy y solicita acceso al llavero de inicio de sesión. En Linux, genera una CA raíz nueva en memoria para cada ejecución y nunca escribe la clave privada en disco. Solo escribe local-ca.pem y configura SSL_CERT_FILE, NODE_EXTRA_CA_CERTS, REQUESTS_CA_BUNDLE, CURL_CA_BUNDLE, GIT_SSL_CAINFO y DENO_CERT para que apunten a ese archivo.
4. Limpieza del entorno: El proxy elimina las variables que coinciden con *TOKEN*, *SECRET*, *PASSWORD*, *API_KEY*, *PRIVATE_KEY* o *ACCESS_KEY*, además de SSH_AUTH_SOCK e INFISICAL_*. Las cuentas de autenticación de dispositivo agregadas mediante orca-ide account add --agent claude o codex siguen funcionando porque su estado de autenticación reside en ~/.claude y ~/.codex, no en variables de entorno [INFERENCE]. Pasa --pass-env=ANTHROPIC_API_KEY solo si te autenticas con variables de entorno que contienen claves de API sin protección.
5. Ocultamiento de rutas de credenciales: bwrap oculta las rutas existentes del host, incluidas ~/.infisical, ~/infisical-keyring, ~/.aws, ~/.ssh, ~/.gnupg, ~/.kube, ~/.netrc, ~/.npmrc, ~/.git-credentials y ~/.config/gh, mediante montajes tmpfs vacíos o /dev/null. Solo el worktree activo de Orca, ~/.claude, ~/.claude.json y ~/.codex conservan permisos de lectura y escritura.

Mejora opcional: separación en dos VM con Oracle Always Free

En el modo de una sola VM, el proceso proxy del host reside en la misma máquina que el agente aislado. Para lograr aislamiento a nivel de host por $0, combina las dos configuraciones de Oracle Always Free en una misma VCN privada [INFERENCE]:

• VM 1 (VM.Standard.E2.1.Micro, 1 GB de RAM, subred privada): Ejecuta infisical sm agent-proxy start en el puerto 17322 (restringido por las reglas de seguridad de la VCN a la subred privada) mediante una Machine Identity de proxy (Read Value, Describe Secret, Report Usage) (Agent Proxy independiente de Infisical, consultado el 2026-11-02). Renueva automáticamente su token de Universal Auth y consulta los secretos cada 60 segundos.
• VM 2 (VM.Standard.A1.Flex, 12 GB de RAM, host del workspace): Ejecuta orca-ide serve y conecta agentes mediante infisical sm agent-proxy connect --proxy=<micro-private-ip>:17322 --env=dev --path=/coding-agent -- claude. Su Machine Identity de agente solo tiene el permiso Proxy y no puede leer los valores de los secretos de Infisical.

5. Problemas comunes en VM Linux y sus soluciones

• AppArmor de Ubuntu 24.04 bloquea los namespaces de usuario de bwrap: Ubuntu 24.04 establece kernel.apparmor_restrict_unprivileged_userns=1. Si bwrap no puede crear un namespace de usuario, infisical sm agent-proxy run se niega a iniciar y muestra instrucciones para solucionar el problema (Agent Proxy local de Infisical, consultado el 2026-11-02). Confirma que /etc/apparmor.d/bwrap esté cargado (sudo apparmor_parser -r /etc/apparmor.d/bwrap) o comprueba sysctl kernel.apparmor_restrict_unprivileged_userns.
• Los servidores de desarrollo dentro de agent-proxy run son inaccesibles: Como bwrap aísla el namespace de red, un servidor iniciado dentro de agent-proxy run es invisible para el host y para el reenvío de puertos de Orca, y el agente no puede acceder a 127.0.0.1:5432 en la VM. Ejecuta los servidores de desarrollo y las pruebas de bases de datos en otra pestaña de Orca fuera de bwrap.
• El tráfico que no es HTTP falla a través del proxy: Agent Proxy solo intermedia tráfico HTTP y HTTPS (HTTP/1.1). Los pushes de git por SSH (git@github.com:...), las conexiones TCP directas a Postgres y WebSockets fallan dentro de agent-proxy run (Agent Proxy local de Infisical, consultado el 2026-11-02). Usa remotos https://github.com/... con un token de GitHub gestionado por el proxy o haz push por SSH desde una pestaña normal de Orca.

6. Lista de verificación

Ejecuta estas tres comprobaciones en una terminal de un worktree de Orca antes de iniciar el trabajo con agentes:

1. Confirma que node_modules sea un enlace simbólico (lrwxrwxrwx), no una copia:

ls -ld "$PWD/node_modules"

2. Confirma que no exista ningún archivo .env en el worktree (la salida debe estar vacía):

find "$PWD" -maxdepth 2 -name ".env*"

3. Confirma que bwrap elimine INFISICAL_TOKEN y oculte ~/.infisical/client-secret:

infisical sm agent-proxy run --env=dev --path=/coding-agent -- \
  sh -c 'echo "token=${INFISICAL_TOKEN:-scrubbed}"; ls -la ~/.ssh ~/.infisical; cat ~/.infisical/client-secret 2>&1 || true'

Si ese comando muestra token=scrubbed y no puede leer ~/.infisical/client-secret, tu workspace está listo. Ahora cada worktree nuevo de Orca comparte node_modules sin consumir espacio adicional en disco, se ejecuta dentro de límites de memoria por terminal y mantiene las credenciales sin protección de .env fuera del sistema de archivos y del entorno de proceso del agente [INFERENCE].

Fuentes

Consultamos todas las fuentes siguientes el 2 de noviembre de 2026:

• Orca (stablyai/orca):
  • Formas de ejecutar Orca y Worktrees por SSH — SSH Target frente a Remote Orca Server, ~/.orca-remote/ (orcad) y requisitos de build-essential python3 para node-pty.
  • Servidores remotos de Orca, Issue #28320 / PR #28871 y Referencia del servidor Linux sin interfaz gráfica — orca-ide serve --pairing-address, vinculación con Tailscale, orca-ide account add --agent, loginctl enable-linger y scopes de systemd de ORCA_TERMINAL_MEMORY_MAX.
  • Instalar Orca y Referencia de la CLI de Orca — nombre del binario orca-ide en Linux (conflicto con el lector de pantalla de GNOME en /usr/bin/orca).
  • Worktrees y Referencia de orca.yaml y .worktreeinclude (PR #9791, PR #10459) — worktree.sharedDirectories, límites de .worktreeinclude, reglas de defaultTabs y por qué el modo SSH Target usa scripts.setup.
  • Discusión de GitHub #29584: worktrees en contenedores (publicada el 2026-10-16) — flags predeterminados de Orca que omiten permisos (docs/site/content/docs/agents/supported.mdx) y límites de aislamiento de los worktrees.
• Infisical:
  • Agent Proxy local de Infisical — infisical sm agent-proxy run, sandbox de bubblewrap (bwrap) en Linux, puente de loopback hacia proxy.sock, CA raíz en memoria, limpieza del entorno y comportamiento de AppArmor en Ubuntu 24.04.
  • Agent Proxy independiente de Infisical y Servicios gestionados por proxy — infisical sm agent-proxy start (puerto 17322), connect, consultas cada 60 segundos y roles de Machine Identity de proxy frente a agente.
  • Referencia de la CLI de Infisical, sección de inicio de sesión de la CLI, configuración del proyecto (.infisical.yaml) y OCI Auth — versiones mínimas 0.43.145 y 0.44.8 de la CLI, version: 1, --method=universal-auth / aws-iam / gcp-id-token y requisitos de --projectId en sm run.
• Niveles gratuitos de proveedores cloud (cuotas variables verificadas el 2026-11-02):
  • Recursos Always Free de Oracle Cloud — límite de VM.Standard.A1.Flex del 15 de junio de 2026 (1,500 horas de OCPU y 9,000 horas de GB al mes, o 2 OCPU / 12 GB de RAM de forma continua), VM.Standard.E2.1.Micro, 200 GB de Block Volume y reglas de recuperación por inactividad durante 7 días.
  • AWS Free Tier — programa de créditos del 15 de julio de 2025 (hasta $200 USD en créditos; Free Plan de 6 meses frente a Paid Plan de 12 meses).
  • Programa gratuito de Google Cloud — e2-micro de Always Free (1 GB de RAM en us-west1, us-central1 o us-east1, 30 GB de Standard Persistent Disk).
  • GitHub Codespaces — 120 horas-núcleo al mes y 15 GB de almacenamiento en cuentas personales.