OpenCode Web nel browser: imposta la porta e proteggi l’accesso

OpenCode Web è l’interfaccia browser del server OpenCode. Serve per vedere le sessioni, aprire un progetto in una scheda o avere una seconda vista senza usare sempre la TUI. Rimane un servizio locale di sviluppo, non un account ospitato che sostituisce le credenziali del provider.

Il primo comando dovrebbe essere opencode web, senza cambiare l’hostname. La documentazione ufficiale indica 127.0.0.1, una porta disponibile e l’apertura del browser predefinito. Questo confine locale permette di controllare progetto, provider, permessi e sessioni.

Solo dopo scegli una porta fissa, un hostname di rete, mDNS o CORS. Ogni opzione cambia chi può collegarsi. Un browser che non si apre indica spesso processo o porta; un’esposizione indesiderata è un problema di confine.

opencode web

Esegui il comando nel repository che vuoi usare. OpenCode avvia il server Web e apre il browser. Lascia visibile il terminale proprietario del processo per annotare indirizzo, porta e avvisi. Una scheda aperta non prova che file e modello siano corretti.

Per un ambiente ripetibile usa opencode web --port 4096. Una porta fissa aiuta segnalibri, script e opencode attach, ma può collidere con un altro processo. Individua il proprietario della porta invece di pubblicare tutte le porte.

La prima attività Web dovrebbe essere in sola lettura: elenca il progetto, riassumi un file piccolo e controlla sessione o stato del server. Poi verifica Git status e modello nello stesso workspace. Così browser, processo, repository e provider restano distinguibili.

La porta è un numero dell’host; l’hostname stabilisce quali interfacce accettano connessioni. 127.0.0.1 è locale. --port 4096 cambia il numero, mentre --hostname 0.0.0.0 amplia l’ascolto alle interfacce di rete.

mDNS è comodo su una rete locale affidabile. L’esempio ufficiale usa opencode web --mdns e annuncia opencode.local; --mdns-domain separa più istanze. La scoperta non cifra il traffico e non sostituisce l’autenticazione.

CORS definisce quali origini browser possono fare richieste cross-origin. Può servire a un frontend, ma non rende privato un server esposto. Mantieni l’elenco preciso e prova l’Origin reale.

L’avviso ufficiale è chiaro: senza OPENCODE_SERVER_PASSWORD il server non è protetto. Può andare bene per una prova solo locale, non per un listener raggiungibile da altri dispositivi. Inietta la password all’avvio e non salvarla in opencode.json, cronologia, screenshot o .env committati.

L’utente predefinito è opencode; OPENCODE_SERVER_USERNAME permette di cambiarlo. Queste credenziali proteggono il server Web, non provider o repository. Controlla separatamente chiavi, permessi, mount e utente del processo.

Prima di --hostname 0.0.0.0, verifica firewall e segmento di rete. Preferisci rete privata, password temporanea e porta nota. Con proxy, VPN o frontend, indica dove termina TLS e quale livello vede ancora la sessione.

La home Web mostra le sessioni attive e permette di crearne. Conferma il progetto prima del prompt. Una scheda può restare aperta dopo il cambio di processo o repository, quindi controlla di nuovo lo stato del server.

Lo stato del server separa processo Web e sessione di coding. Se manca il modello, controlla provider e ID; se mancano file, controlla directory di lavoro e utente prima di modificare il prompt.

Per usare entrambe le interfacce avvia Web e lancia opencode attach http://localhost:4096 in un altro terminale. La documentazione descrive sessioni e stato condivisi. Mantieni un solo autore delle scritture e rivedi ogni diff piccolo.

La pagina Web ufficiale consiglia WSL su Windows per una migliore integrazione di file e terminale. È importante se il repository è su un percorso Linux, gli strumenti sono in WSL o PowerShell usa PATH e home diversi.

Annota dove gira il comando, dove si trova il repository e quale utente possiede il processo. Un browser Windows può raggiungere WSL, ma localhost, firewall e percorsi possono attraversare un confine invisibile al terminale. Prova prima in sola lettura.

Se la pagina si apre ma comando o riferimento fallisce, confronta opencode --version, directory, variabili del provider e shell che ha avviato Web. Le guide deployment, VS Code e permessi coprono i livelli vicini; qui il focus è il server browser.

Parti da processo e URL e vai verso il progetto. Un errore di connessione riguarda processo, porta, hostname, firewall o CORS. Una pagina che carica ma non crea sessione riguarda progetto, provider, permessi o modello. Cambiare tutto insieme elimina le prove.

Con una porta fissa controlla chi ascolta e lo stesso numero nell’URL stampato. Con hostname di rete prova localhost e password prima del secondo dispositivo. Con mDNS confronta nome annunciato e indirizzo reale.

Quando una sessione è inattesa, salva comando, directory, ID modello, origine delle variabili e Git status. Ripeti una richiesta breve in lettura e una modifica piccola. Fermati se il diff include segreti, file estranei o percorsi fuori dal worktree.

Scegli Web quando il browser facilita la revisione di progetto e conversazione, quando serve una seconda vista del server o quando il team vuole un URL locale ripetibile. La TUI resta migliore per tastiera, shell intenso o ambienti senza browser.

Web non sostituisce le guide provider, permessi o Docker: cambia solo l’accesso al server. Credenziali, permessi, mount, strumenti MCP e revisione Git richiedono i propri controlli. Collega la guida più specifica per la decisione successiva.

Una routine stabile è: avviare in locale, verificare progetto e modello, mettere una password prima di ampliare hostname, annotare la porta, collegare TUI solo se serve e arrestare il server alla fine. Un listener di sviluppo non diventa così un servizio pubblico.