Unchained Sky

Servidor MCP de automação de navegador que conecta agentes de IA ao seu navegador Chrome real com compreensão estruturada de páginas em ~500 tokens

GitHub
2
Experimente este MCPPatrocinado

Documentação

Unchained Infra

Infraestrutura aberta e plano de controle para o Unchained, um sistema de automação de navegador construído sobre o Chrome DevTools Protocol.

A maioria dos agentes de navegador falha na autenticação. O Unchained evita isso ao conduzir a própria sessão Chrome do usuário, com seus cookies, extensões, IP e estado de 2FA existentes, em vez de repetir logins frágeis em um sandbox.

Este repositório contém as partes públicas desse sistema: relay, interface web, empacotamento de agentes, ponte de navegador, ativos de implantação e orquestração de servidor. O mecanismo proprietário de extração fica atrás de um limite de runtime documentado em um repositório privado separado.

O que há neste repositório

  • unchained/web.py: interface de chat, fluxos de autenticação, interface do agendador, transporte de chat SSE
  • unchained/relay.py: relay WebSocket para túneis de agente de navegador e clientes CDP
  • unchained/chrome_bridge.py: ponte local ou headless do Chrome CDP para o relay
  • unchained/chat_agent_cli.py: pistas locais de agente para Claude CLI, Codex CLI, OpenCode CLI e backends de modelo relacionados
  • unchained/chat_agent_openrouter.py: worker de inferência OpenRouter hospedado para a pista de teste híbrida (o navegador ainda roda através do conector do usuário)
  • unchained/credit.py: livro-razão de inferência hospedada baseado em concessões e retenções por chamada
  • unchained/agent_package.py: gerador de pacotes de agente para download
  • docker-compose.yml: topologia de implantação de produção
  • deploy.sh e deploy_headless.sh: pontos de entrada de implantação EC2

O que permanece privado

O DDM, a inteligência de página e a lógica principal de execução CDP não são armazenados neste repositório. O código público fala com essa camada através de private_core_client.py.

Essa divisão é intencional:

  • o código do relay, da interface, da autenticação, do empacotamento e da implantação está aberto para inspeção
  • as heurísticas de extração de navegador de alto impacto permanecem no repositório principal privado
  • o CI aplica o limite com guardas de importação e verificações de artefatos

Consulte docs/open-core-split-plan.md para o modelo atual de open-core.

Por que desenvolvedores podem avaliar este repositório

  • O túnel de navegador está aqui. Você pode inspecionar como a autenticação de agente, o roteamento do relay e o proxy CDP realmente funcionam.
  • O caminho de implantação está aqui. Docker Compose, roteamento Caddy, scripts de implantação EC2 e definições de worker headless fazem parte do repositório público.
  • O limite de confiança é explícito. Os serviços públicos não importam diretamente módulos privados de inteligência de navegador.
  • O caminho de desenvolvimento local é real. Você pode executar o relay e o aplicativo web localmente com ./dev.sh.

Forma do 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

Mais detalhes: docs/architecture.md

Início rápido

Desenvolvimento local

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

Em seguida, abra http://localhost:8080.

Se o Google OAuth não estiver configurado, o aplicativo usa autenticação de desenvolvimento como alternativa:

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

dev.sh inicia apenas o servidor web local e o relay. Para conectar um cliente de chat local e um Chrome controlado sem enviar tráfego de teste para produção, siga docs/local-agent-testing.md. A sessão do navegador, o cliente de chat e a ponte Chrome devem usar a mesma chave de API armazenada localmente.

O worker de teste hospedado não é iniciado por dev.sh. Implantações Docker que o habilitam devem definir um HOSTED_AGENT_SERVICE_TOKEN dedicado; ele não deve reutilizar TRIAL_AGENT_KEY, PRIVATE_CORE_TOKEN ou uma chave de API de usuário.

Implantação em produção

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 rejeita worktrees sujos e qualquer revisão diferente da origin/main atual. Ele aplica e restaura a sobreposição do núcleo privado somente após essa verificação de origem ser bem-sucedida. A proteção exige que origin esteja acessível e falha de forma segura se não conseguir consultar a revisão atual do main.

Verificação

Estas são as verificações mais rápidas para o limite do repositório público e a pilha 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

Estrutura do repositório

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

Documentação

Licença

MIT