Segurança

O OpenChamber dá acesso à sua máquina e ao seu código, então proteja-o antes que qualquer pessoa além de você possa alcançá-lo. Esta página cobre a senha de UI, as passkeys e o que saber antes de expor o OpenChamber a uma rede.

Definir uma senha de UI

Inicie o OpenChamber com uma senha e a UI do navegador a solicita:

openchamber --ui-password be-creative-here

Você também pode defini-la com a variável de ambiente OPENCHAMBER_UI_PASSWORD em vez de colocá-la na linha de comando. Após o login, o OpenChamber lembra o dispositivo por um tempo para que você não seja solicitado toda vez.

Sempre defina uma senha se a instância puder ser alcançada por outra pessoa — especialmente por um túnel ou pela internet pública.

Passkeys

Uma vez definida uma senha, você pode adicionar passkeys (Face ID, Touch ID, uma chave de segurança) para um login mais rápido. Adicione-as em Settings → OpenChamber → Passkeys.

As passkeys estão vinculadas à senha atual. Se você alterar ou remover a senha, as passkeys salvas são apagadas e você precisará adicioná-las novamente.

Tokens de dispositivo

Os dispositivos pareados por Conectar um Dispositivo se autenticam com os próprios tokens por dispositivo, não com a senha de UI. Os links de pareamento são de uso único e expiram se não forem usados; cada dispositivo pareado é listado em Settings → Remote Instances → Conectar a este servidor, onde você pode revogar qualquer um deles a qualquer momento. As conexões fora de casa passam pelo Private Relay, que é criptografado de ponta a ponta e não consegue ler o seu tráfego.

Antes de expô-lo

• Por padrão, o OpenChamber só escuta na sua própria máquina (127.0.0.1). É preciso uma mudança deliberada para escutar mais amplamente, e você deve definir uma senha primeiro.
• Para os seus próprios dispositivos, prefira o pareamento com o Private Relay — nada fica exposto publicamente.
• Se você precisa de uma URL pública, prefira um túnel ou uma rede privada (como uma VPN) a abrir uma porta para a internet.
• Se você colocar o OpenChamber atrás do seu próprio servidor HTTPS, veja Reverse Proxy.

Modo empresarial

Se a sua equipe só pode enviar o conteúdo das conversas aos provedores de modelos que você configurou no OpenCode, ative o modo empresarial. Há dois jeitos de fazer isso, e qualquer um deles basta.

Um arquivo de política na máquina

É o jeito certo para os notebooks que você gerencia. Coloque um arquivo chamado policy.json em uma pasta onde só um administrador pode escrever:

Sistema	Caminho
macOS	/Library/Application Support/OpenChamber/policy.json
Windows	C:\ProgramData\OpenChamber\policy.json
Linux	/etc/openchamber/policy.json

O caminho não depende de como o OpenChamber foi instalado. O app desktop, o servidor web iniciado pelo npm, a CLI e a extensão do VS Code leem o mesmo arquivo. Você pode distribuí-lo com o seu gerenciador de dispositivos (Jamf, Intune e similares). Para um servidor no Docker, monte o arquivo no caminho do Linux.

{
  "enterpriseMode": true,
  "organization": "Acme",
  "relayUrl": "wss://relay.acme.com/ws",
  "allowNetworkAccess": false,
  "allowedExtensions": ["https://github.com/acme/"],
  "jev": {
    "url": "https://llm.acme.com/v1/systemone",
    "model": "acme-classifier",
    "apiKey": "..."
  }
}

Só enterpriseMode é obrigatório. organization aparece nas Configurações como “Gerenciado por Acme”, para que as pessoas saibam quem tomou a decisão. relayUrl e jev fixam o seu próprio relay e o seu próprio endpoint do Jev, allowNetworkAccess deixa outros dispositivos acessarem o OpenChamber pela rede, e allowedExtensions lista os repositórios de extensões em que você confia. Todos estão descritos abaixo.

• Nada que um usuário defina, nas Configurações ou no ambiente, desliga o que o arquivo liga.
• Quando o arquivo liga o modo empresarial, só o arquivo decide. As variáveis de ambiente abaixo para o relay, o Jev e o acesso pela rede são ignoradas, porque um usuário pode defini-las por conta própria.
• Se o arquivo existe mas não pode ser lido ou não é um JSON válido, o modo empresarial continua ativo e nada é fixado. As Configurações avisam que a política não pôde ser lida. Um arquivo quebrado nunca remove a proteção sem avisar.
• As mudanças valem sem reiniciar.
• O OpenChamber roda como o usuário, então o usuário consegue ler o arquivo. Leve isso em conta antes de colocar uma chave de API nele.

Uma variável de ambiente

Em um servidor ou em um contêiner, onde você controla o ambiente, isto basta:

OPENCHAMBER_ENTERPRISE_MODE=1

Em um notebook é uma trava mais fraca: o app desktop lê a variável do perfil do shell de login (por exemplo, ~/.zshrc), e o usuário pode editar esse arquivo. Nesse caso, use o arquivo de política.

Com a variável, o relay, o Jev, o acesso pela rede e as extensões permitidas também vêm das próprias variáveis: OPENCHAMBER_RELAY_URL, OPENCHAMBER_JEV_URL, OPENCHAMBER_ALLOW_NETWORK_ACCESS=1, OPENCHAMBER_ALLOWED_EXTENSIONS (URLs de repositórios separadas por vírgulas) e OPENCHAMBER_ALLOW_LOCAL_EXTENSIONS=1. No Docker você vai precisar da de acesso pela rede, já que o servidor tem que escutar além do contêiner.

Fixar a CLI do OpenCode

Se as suas máquinas já têm o OpenCode instalado e o OpenChamber deve usar essa instalação, coloque o caminho dela no arquivo de política. Funciona com ou sem o modo empresarial.

{
  "opencodeBinary": "/usr/local/bin/opencode"
}

• O OpenChamber inicia o OpenCode só a partir desse caminho. Ele ignora o caminho das Configurações, o OPENCODE_BINARY e a cópia que vem com o app desktop, que fica no disco sem uso.
• Se não houver nada executável nesse caminho, o OpenChamber não recorre a outra cópia. Ele para com um erro que mostra o caminho.
• As Configurações mostram o caminho só para leitura, com um aviso de que o administrador o definiu.
• O OpenChamber não instala nem atualiza um OpenCode fixado e não anuncia versões novas. As atualizações chegam com a sua distribuição.
• A CLI precisa ser o OpenCode 2.x, no mínimo na versão que o OpenChamber pede. Com uma mais antiga, o OpenChamber para na tela de “atualizar o OpenCode”.
• Uma pasta também serve, se tiver o opencode (opencode.exe no Windows). Não existe variável de ambiente para isso, porque o usuário pode defini-las por conta própria.

Ocultar os catálogos de skills embutidos

O OpenChamber vem com alguns catálogos públicos de skills (Anthropic, OpenAI, Cursor, Matt Pocock). Se sua organização mantém um próprio, adicione-o como catálogo personalizado e oculte os embutidos no arquivo de política. Funciona com ou sem o modo empresarial.

{
  "hideBuiltinSkillCatalogs": true
}

As configurações passam a oferecer só os catálogos que as pessoas adicionam, e o OpenChamber não carrega um embutido nem se for pedido diretamente. Não há variável de ambiente para isso, porque o usuário pode defini-las.

Exemplos

Para colocar o arquivo de política num Mac, rode no Terminal como administrador:

sudo mkdir -p "/Library/Application Support/OpenChamber"
sudo tee "/Library/Application Support/OpenChamber/policy.json" > /dev/null <<'JSON'
{
  "enterpriseMode": true,
  "organization": "Acme"
}
JSON

No Linux é igual, com /etc/openchamber como pasta.

No Windows, rode o PowerShell como administrador. A última linha deixa só os administradores e o sistema escreverem na pasta:

New-Item -ItemType Directory -Force "C:\ProgramData\OpenChamber" | Out-Null
@'
{
  "enterpriseMode": true,
  "organization": "Acme"
}
'@ | Set-Content -Encoding UTF8 "C:\ProgramData\OpenChamber\policy.json"
icacls "C:\ProgramData\OpenChamber" /inheritance:r /grant:r "Administrators:(OI)(CI)F" "SYSTEM:(OI)(CI)F" "Users:(OI)(CI)RX"

Um servidor no Docker, adicionado ao environment do docker-compose.yml. O contêiner escuta além de si mesmo, então precisa do acesso pela rede liberado:

environment:
  OPENCHAMBER_UI_PASSWORD: ${OPENCHAMBER_UI_PASSWORD}
  OPENCHAMBER_ENTERPRISE_MODE: "1"
  OPENCHAMBER_ALLOW_NETWORK_ACCESS: "1"
  # Optional:
  OPENCHAMBER_RELAY_URL: wss://relay.acme.com/ws
  OPENCHAMBER_JEV_URL: https://llm.acme.com/v1/systemone
  OPENCHAMBER_JEV_MODEL: acme-classifier
  OPENCHAMBER_JEV_API_KEY: ${ACME_JEV_KEY}
  OPENCHAMBER_ALLOWED_EXTENSIONS: https://github.com/acme/

Para conferir se funcionou, abra Configurações → Provedores: um aviso de modo empresarial com o nome da sua organização aparece no topo.

O que muda

• Os provedores de modelos vêm só da sua configuração do OpenCode. Conectar um provedor, entrar em um, adicionar uma chave ou criar um provedor personalizado fica desativado no OpenChamber; remover ou trocar contas que já existem continua funcionando. Isso só fecha a entrada pelo app; a trava em si é a política do OpenCode descrita abaixo. Entrar em um servidor MCP da sua configuração do OpenCode continua funcionando, porque isso chega a esse servidor e não a um provedor de modelos.
• Os Provedores de classificação (Jev) ficam desativados, inclusive um endpoint personalizado que alguém digite nas Configurações. A rede de segurança e o Auto não são oferecidos, e as sessões em andamento não recebem a dica “parece concluído”. Para usar o Jev pela sua própria infraestrutura, fixe um endpoint com jev no arquivo de política ou com OPENCHAMBER_JEV_URL (mais OPENCHAMBER_JEV_MODEL e, se ele precisar, OPENCHAMBER_JEV_API_KEY). Ele passa a ser o padrão, ainda dá para desativá-lo e nada mais pode ser escolhido.
• A leitura em voz alta pela OpenAI fica desativada. Um servidor próprio de fala ou de transcrição precisa rodar na mesma máquina. Vozes locais e modelos locais de ditado continuam funcionando.
• As notificações push para celulares e navegadores levam só um título genérico como “Agent response is ready”, sem o texto da mensagem nem o nome da sessão. As notificações do desktop ficam na sua máquina e mantêm o texto completo.
• As verificações de atualização continuam rodando, então as correções de segurança ainda chegam até você, mas elas nunca reportam uso, nem mesmo o ID de instalação anônimo.
• Os túneis externos (Cloudflare, ngrok) ficam desativados. Um provedor de túnel descriptografa o tráfego na borda dele e vê cada requisição em texto puro.
• Diagramas .drawio abrem como texto XML. O editor de diagramas é uma página do diagrams.net, e abrir um diagrama nele entrega o arquivo a essa página.
• Fontes de interface e de código que carregam de uma CDN pública passam para as fontes do sistema. Sua escolha fica guardada para quando o modo estiver desligado.
• O Private Relay só funciona pelo seu próprio relay. Rode um relay auto-hospedado e aponte o OpenChamber para ele com relayUrl no arquivo de política ou com OPENCHAMBER_RELAY_URL=wss://relay.example.com/ws. O relay compartilhado também não consegue ler o seu tráfego, já que é criptografado de ponta a ponta, mas o seu próprio mantém os metadados de conexão e a entrada para esta máquina dentro da sua rede. Sem o seu próprio relay, não dá para parear nenhum dispositivo.
• O OpenChamber escuta só na máquina em que roda. A configuração do desktop que deixa outros dispositivos da rede local abrirem o app fica desativada, e o servidor se recusa a iniciar em um endereço de rede, seja pela CLI (--host, --lan) ou pelo ambiente. Se o arquivo de política aparecer com o app rodando, as conexões de outras máquinas são derrubadas até a próxima inicialização. Libere o acesso pela rede com "allowNetworkAccess": true no arquivo de política, ou com OPENCHAMBER_ALLOW_NETWORK_ACCESS=1 onde o ambiente liga o modo empresarial. Lembre que a conexão é HTTP puro, então numa rede compartilhada qualquer um consegue lê-la; coloque um servidor que outras pessoas acessam atrás do seu próprio HTTPS.
• Extensões que podem mandar dados para fora da máquina (as que falam com uma API externa, carregam de endereços externos ou rodam um serviço em segundo plano) só são instaladas a partir de um repositório Git listado em allowedExtensions. Extensões que não fazem nada disso são instaladas normalmente. Uma extensão instalada de qualquer outro lugar fica desativada, e as Configurações dizem o motivo. A lista traz URLs de repositórios, já que cada extensão escolhe o próprio nome; uma entrada terminada em /, como https://github.com/acme/, libera todos os repositórios abaixo dela. Nas máquinas de quem desenvolve extensões, "allowLocalExtensions": true também libera a instalação a partir de uma pasta local. Um ZIP continua bloqueado de qualquer forma.
• Variáveis de ambiente de Configurações → Geral e de opencode service set env não chegam ao OpenCode, já que uma delas pode carregar uma chave de provedor. O Git, o terminal e as ações de projeto continuam recebendo essas variáveis.
• Na extensão do VS Code, conectar provedores fica desativado e as verificações de atualização não reportam uso. Ela já não tem Jev, relay, túneis, notificações push nem voz na nuvem.

As tarefas do modelo pequeno (títulos de sessão, resumos, mensagens de commit, o percurso de mudanças) não precisam de nenhum modo especial. Elas sempre rodam no modelo pequeno que você escolheu nas Configurações, em um modelo pequeno do provedor com que você está trabalhando ou no modelo padrão da sua configuração do OpenCode. Elas nunca recorrem a outro provedor que você por acaso tenha conectado.

Quais provedores de modelos podem ser usados é o OpenCode que decide, não o OpenChamber. Trave isso com as políticas do OpenCode: negue todos os provedores e depois permita os que você aprovou.

{
  "experimental": {
    "policies": [
      { "action": "provider.use", "resource": "*", "effect": "deny" },
      { "action": "provider.use", "resource": "anthropic", "effect": "allow" }
    ]
  }
}

Um provedor negado desaparece mesmo que alguém adicione uma chave para ele. Coloque as políticas no arquivo global ~/.config/opencode/opencode.jsonc, onde um projeto não consegue removê-las, ou distribua-as a partir de um workspace do OpenCode Console, que tem a palavra final. O modo empresarial cobre, além disso, o que o próprio OpenChamber envia.

As buscas na web e os acessos a páginas feitos pelo agente também passam pelo OpenCode, até o serviço de busca e até as próprias páginas. Se eles não devem sair da sua rede, negue-os com o mesmo tipo de política:

{ "action": "permission", "resource": "websearch:*", "effect": "deny" },
{ "action": "permission", "resource": "webfetch:*", "effect": "deny" }

Relacionado

• Conectar um Dispositivo — pareamento de uso único e tokens por dispositivo
• Private Relay — acesso criptografado de ponta a ponta de qualquer lugar
• Túneis — exponha uma URL pública quando precisar de uma
• Reverse Proxy — execute o OpenChamber atrás do seu próprio servidor