OpenCode Web no navegador: configure a porta e proteja o acesso

O OpenCode Web é a interface do navegador para o servidor OpenCode. Ele ajuda a ver sessões, abrir um projeto em uma aba ou manter uma segunda visão sem trabalhar sempre na TUI. Continua sendo um serviço de desenvolvimento local, não uma conta hospedada que substitui credenciais do provedor.

O primeiro comando deve ser opencode web, sem alterar o hostname. A documentação oficial informa que o servidor usa 127.0.0.1, escolhe uma porta disponível e abre o navegador padrão. Essa barreira local permite validar projeto, provedor, permissões e sessões.

Só depois escolha uma porta fixa, hostname de rede, mDNS ou CORS. Cada opção muda quem pode conectar. Um navegador que não abre geralmente indica processo ou porta; uma exposição indevida é um problema de limite e exige reduzir o alcance.

opencode web

Execute o comando no repositório que deseja usar. O OpenCode inicia o servidor Web e abre o navegador. Mantenha visível o terminal que possui o processo para registrar endereço, porta e avisos. Uma aba aberta não prova que arquivos e modelo estão corretos.

Para uma configuração repetível use opencode web --port 4096. A porta fixa facilita favoritos, scripts e opencode attach, mas pode colidir com outro processo. Descubra quem ocupa a porta antes de publicar todas as portas do computador.

A primeira tarefa Web deve ser somente leitura: listar o projeto, resumir um arquivo pequeno e verificar sessão ou status do servidor. Depois confira Git status e o modelo no mesmo workspace. Assim navegador, processo, repositório e provedor ficam separáveis.

A porta é um número do host; o hostname define quais interfaces aceitam conexões. 127.0.0.1 é local. --port 4096 muda o número, enquanto --hostname 0.0.0.0 amplia a escuta para interfaces de rede.

mDNS é conveniente em uma rede local confiável. O exemplo oficial usa opencode web --mdns e anuncia opencode.local; --mdns-domain separa várias instâncias. Descoberta não criptografa o tráfego nem substitui autenticação.

CORS define quais origens do navegador podem fazer requisições entre domínios. Pode ser necessário para um frontend próprio, mas não deixa privado um servidor exposto. Mantenha a lista exata e teste o Origin real.

O aviso oficial é direto: sem OPENCODE_SERVER_PASSWORD o servidor fica sem proteção. Isso pode servir para um teste local, mas não para um listener acessível por outro dispositivo. Injete a senha no processo e não a coloque em opencode.json, histórico, captura ou .env commitado.

O usuário padrão é opencode; OPENCODE_SERVER_USERNAME permite alterá-lo. Essas credenciais protegem o servidor Web, não o provedor nem o repositório. Analise separadamente chaves, permissões, volumes e usuário do processo.

Antes de --hostname 0.0.0.0, revise firewall e segmento de rede. Prefira rede privada, senha temporária e porta conhecida. Com proxy, VPN ou frontend, registre onde TLS termina e qual camada ainda enxerga a sessão.

A página inicial Web mostra sessões ativas e cria novas. Confirme o projeto antes de enviar um prompt. Uma aba pode permanecer após mudar o processo ou repositório, então verifique o status do servidor novamente.

O status diferencia processo Web e sessão de codificação. Se faltar modelo, confira provedor e ID; se faltarem arquivos, confira diretório e usuário antes de alterar prompt ou reinstalar a CLI.

Para usar as duas interfaces, inicie Web e rode opencode attach http://localhost:4096 em outro terminal. A documentação descreve sessões e estado compartilhados. Mantenha um único autor das escritas e revise cada diff pequeno.

A página Web oficial recomenda usar WSL no Windows para melhor integração de arquivos e terminal. Isso importa quando o repositório está em caminho Linux, as ferramentas vivem no WSL ou PowerShell tem outro PATH e home.

Registre onde o comando roda, onde está o repositório e qual usuário possui o processo. Um navegador do Windows pode alcançar o WSL, mas localhost, firewall e caminhos podem cruzar um limite invisível no terminal. Teste somente leitura antes de editar.

Se a página abre mas comando ou referência falha, compare opencode --version, diretório atual, variáveis do provedor e o shell que iniciou Web. Os guias de implantação, VS Code e permissões cobrem camadas vizinhas; aqui o foco é o servidor do navegador.

Comece pelo processo e URL e avance para dentro. Erro de conexão aponta para processo, porta, hostname, firewall ou CORS. Página que abre sem criar sessão aponta para projeto, provedor, permissões ou modelo. Alterar tudo de uma vez elimina a evidência.

Com porta fixa, confira quem está ouvindo e se a URL usa o mesmo número. Com hostname de rede, teste localhost e senha antes do segundo dispositivo. Com mDNS, compare o nome anunciado com o endereço real.

Quando uma sessão agir diferente, salve comando, diretório, ID do modelo, origem das variáveis e Git status. Reproduza uma requisição curta de leitura e uma mudança pequena. Pare se o diff tiver segredos, arquivos estranhos ou caminhos fora do worktree.

Use Web quando o navegador facilitar revisar projeto e conversa, quando precisar de uma segunda visão do servidor ou quando o time quiser uma URL local repetível. A TUI continua melhor para teclado, shell intenso ou ambientes sem navegador.

Web não substitui os guias de provedor, permissões ou Docker; apenas muda como você chega ao servidor. Credenciais, permissões, volumes, ferramentas MCP e revisão Git mantêm seus próprios controles. Aponte para o guia estreito da próxima decisão.

Uma rotina estável é: iniciar localmente, validar projeto e modelo, definir senha antes de ampliar hostname, registrar a porta, conectar TUI quando necessário e encerrar o servidor ao terminar. Conveniência não transforma listener de desenvolvimento em serviço público.