Unchained Sky

Servidor MCP de automatización de navegador que conecta agentes de IA a tu navegador Chrome real con comprensión estructurada de páginas en ~500 tokens

GitHub
2
Prueba este MCPPatrocinado

Documentación

Infraestructura Unchained

Infraestructura abierta y plano de control para Unchained, un sistema de automatización de navegadores construido sobre el Protocolo de DevTools de Chrome en bruto.

La mayoría de los agentes de navegador fallan en la autenticación. Unchained evita eso manejando la propia sesión de Chrome del usuario, con sus cookies existentes, extensiones, IP y estado de 2FA, en lugar de reproducir inicios de sesión frágiles en un entorno aislado.

Este repositorio contiene las piezas públicas de ese sistema: relay, interfaz web, empaquetado de agentes, puente de navegador, recursos de despliegue y orquestación de servidores. El motor de extracción propietario vive detrás de un límite de tiempo de ejecución documentado en un repositorio privado separado.

Qué hay en este repositorio

  • unchained/web.py: interfaz de chat, flujos de autenticación, interfaz de programación, transporte de chat SSE
  • unchained/relay.py: relay WebSocket para túneles de agente de navegador y clientes CDP
  • unchained/chrome_bridge.py: puente local o sin cabeza de Chrome CDP al relay
  • unchained/chat_agent_cli.py: carriles de agente local para Claude CLI, Codex CLI, OpenCode CLI y backends de modelos relacionados
  • unchained/chat_agent_openrouter.py: trabajador de inferencia OpenRouter alojado para el carril de prueba híbrido (el navegador aún se ejecuta a través del conector del usuario)
  • unchained/credit.py: libro mayor de inferencia alojada basado en concesiones y retenciones por llamada
  • unchained/agent_package.py: generador de paquetes de agente descargable
  • docker-compose.yml: topología de despliegue de producción
  • deploy.sh y deploy_headless.sh: puntos de entrada de despliegue EC2

Qué permanece privado

El DDM, la inteligencia de página y la lógica central de ejecución de CDP no se almacenan en este repositorio. El código público se comunica con esa capa a través de private_core_client.py.

Esa división es intencional:

  • el relay, la interfaz de usuario, la autenticación, el empaquetado y el código de despliegue están abiertos para inspección
  • las heurísticas de extracción de navegador de alto apalancamiento permanecen en el repositorio central privado
  • CI hace cumplir el límite con guardas de importación y verificaciones de artefactos

Consulte docs/open-core-split-plan.md para el modelo actual de código abierto.

Por qué los desarrolladores pueden evaluar este repositorio

  • El túnel del navegador está aquí. Puede inspeccionar cómo funcionan realmente la autenticación del agente, el enrutamiento del relay y el proxy CDP.
  • La ruta de despliegue está aquí. Docker Compose, enrutamiento Caddy, scripts de despliegue EC2 y definiciones de trabajadores sin cabeza son parte del repositorio público.
  • El límite de confianza es explícito. Los servicios públicos no importan directamente módulos privados de inteligencia de navegador.
  • La ruta de desarrollo local es real. Puede ejecutar el relay y la aplicación web localmente con ./dev.sh.

Forma del sistema

Phone / browser
    |
    | HTTPS + SSE
    v
Caddy -> web -> private_core_client -> private core service
   |       |
   |       +-> local chat-agent websocket
   |       +-> hosted trial-agent -> OpenRouter
   |
   +-> relay -> chrome_bridge -> user's Chrome DevTools endpoint

Más detalle: docs/architecture.md

Inicio rápido

Desarrollo local

cd unchained-infra/unchained
uv sync
cd ..
./dev.sh

Luego abra http://localhost:8080.

Si Google OAuth no está configurado, la aplicación recurre a autenticación de desarrollo:

curl -X POST http://localhost:8080/auth/dev \
  -H 'Content-Type: application/json' \
  -d '{"email":"dev@localhost"}'

dev.sh inicia solo el servidor web local y el relay. Para conectar un cliente de chat local y Chrome controlado sin enviar tráfico de prueba a producción, siga docs/local-agent-testing.md. La sesión del navegador, el cliente de chat y el puente de Chrome deben usar la misma clave de API almacenada localmente.

El trabajador de prueba alojado no se inicia con dev.sh. Los despliegues de Docker que lo habiliten deben establecer un HOSTED_AGENT_SERVICE_TOKEN dedicado; no debe reutilizar TRIAL_AGENT_KEY, PRIVATE_CORE_TOKEN o una clave de API de usuario.

Despliegue de producción

cd ~/Projects/unchainedsky_com/unchained-infra
git switch main
git pull --ff-only origin main

DEPLOY_REVISION="$(git rev-parse HEAD)" \
PRIVATE_CORE_SRC=../unchained-core-private/unchained \
KEY_PATH=~/.ssh/unchained-key.pem \
EC2_HOST=<host> \
EC2_USER=<deploy-user> \
./deploy.sh

deploy.sh rechaza árboles de trabajo sucios y cualquier revisión que no sea la origin/main actual. Aplica y restaura la superposición del núcleo privado solo después de que esa verificación de fuente tenga éxito. La guarda requiere que origin sea alcanzable y falla cerrado si no puede consultar la revisión main actual.

Verificación

Estas son las verificaciones más rápidas para el límite del repositorio público y la pila local:

cd unchained-infra/unchained
uv run python test_open_core_boundary.py

cd ..
python3 tools/oss_guard/check_private_imports.py
python3 tools/oss_guard/check_agent_artifact_leaks.py

Estructura del repositorio

unchained-infra/
├── docs/                    # Architecture, setup, roadmap, and design notes
├── deploy/                  # Deployment helpers
├── tools/                   # Private-core overlay + OSS boundary guards
├── unchained/               # Python application code
├── docker-compose.yml       # Production stack
├── docker-compose.headless.yml
└── deploy.sh

Documentación

Licencia

MIT