OpenCode Web dans le navigateur : choisir le port et sécuriser l’accès

OpenCode Web est l’interface navigateur du serveur OpenCode. Elle permet de voir les sessions, d’ouvrir un projet dans un onglet ou d’avoir une seconde vue sans rester dans le TUI. Cela reste un service de développement local et non un compte hébergé qui gère vos identifiants fournisseur.

La première commande est opencode web, sans modifier le hostname. La documentation officielle indique que le serveur se lie à 127.0.0.1, choisit un port libre et ouvre le navigateur par défaut. Cette limite locale permet de vérifier projet, fournisseur, permissions et sessions.

Choisissez seulement ensuite un port fixe, un hostname réseau, mDNS ou une règle CORS. Chaque option change les personnes pouvant se connecter. Une erreur de navigateur concerne souvent le processus ou le port ; une exposition indésirable est un problème de limite.

opencode web

Lancez la commande depuis le dépôt à utiliser. OpenCode démarre le serveur Web et ouvre le navigateur. Gardez le terminal propriétaire du processus le temps de noter adresse, port et avertissements. Une page ouverte ne prouve pas que le bon projet ou le bon modèle est accessible.

Pour une adresse stable, utilisez opencode web --port 4096. Un port fixe facilite signets, scripts et opencode attach, mais peut entrer en collision. Identifiez d’abord le processus qui occupe le port au lieu de publier tous les ports de la machine.

La première tâche doit rester en lecture seule : lister le projet, résumer un petit fichier et vérifier session ou état du serveur. Contrôlez ensuite Git status et le modèle dans le même workspace. Vous obtenez ainsi une preuve séparée pour navigateur, processus, dépôt et fournisseur.

Le port est un numéro du serveur ; le hostname définit les interfaces qui acceptent les connexions. 127.0.0.1 est local. --port 4096 change le numéro, alors que --hostname 0.0.0.0 élargit l’écoute et peut rendre le service joignable sur le réseau.

mDNS est pratique sur un réseau local de confiance. L’exemple officiel utilise opencode web --mdns et publie opencode.local, avec --mdns-domain pour plusieurs instances. La découverte ne chiffre pas le trafic et ne remplace pas l’authentification.

CORS indique quels origins de navigateur peuvent effectuer des requêtes cross-origin. Il peut servir à un frontend précis, mais ne rend pas privé un serveur exposé. Gardez une liste étroite et testez l’Origin réel.

L’avertissement officiel est explicite : sans OPENCODE_SERVER_PASSWORD, le serveur n’est pas protégé. Cela peut convenir à un test local, pas à une écoute accessible par un autre appareil. Injectez le mot de passe au lancement et ne le placez pas dans opencode.json, l’historique, une capture ou un .env commité.

Le nom d’utilisateur par défaut est opencode et OPENCODE_SERVER_USERNAME permet de le changer. Ces identifiants protègent le serveur Web, pas le fournisseur ni le dépôt. Vérifiez séparément clés, permissions, montages et utilisateur du processus.

Avant --hostname 0.0.0.0, contrôlez le pare-feu et le segment réseau. Préférez un réseau privé, un mot de passe temporaire et un port connu. Avec proxy, VPN ou frontend, notez où TLS se termine et quelle couche voit encore la session.

La page d’accueil Web affiche les sessions actives et permet d’en créer. Confirmez le projet avant d’envoyer une requête. Un onglet peut rester ouvert après un changement de processus ou de dépôt ; vérifiez donc l’état du serveur.

L’état du serveur aide à distinguer le processus Web de la session de codage. Si le modèle manque, vérifiez fournisseur et ID ; si les fichiers manquent, vérifiez répertoire de travail et utilisateur avant de modifier le prompt.

Pour utiliser les deux interfaces, démarrez Web puis exécutez opencode attach http://localhost:4096 dans un autre terminal. La documentation décrit des sessions et un état partagés. Gardez un seul auteur pour les écritures et inspectez chaque petit diff.

La page Web officielle recommande WSL sous Windows pour la meilleure intégration des fichiers et du terminal. C’est important si le dépôt est sur un chemin Linux, si les outils sont dans WSL ou si PowerShell utilise un PATH et un home différents.

Notez où la commande s’exécute, où se trouve le dépôt et quel utilisateur possède le processus. Un navigateur Windows peut joindre WSL, mais localhost, pare-feu et chemins peuvent traverser une limite invisible depuis le terminal. Faites d’abord une requête en lecture seule.

Si la page s’ouvre mais qu’une commande échoue, comparez opencode --version, le répertoire, les variables du fournisseur et le shell qui a lancé Web. Les guides de déploiement, VS Code et permissions couvrent les couches voisines ; celui-ci reste centré sur le serveur navigateur.

Commencez par processus et URL, puis avancez vers le projet. Une erreur de connexion concerne processus, port, hostname, pare-feu ou CORS. Une page qui charge mais ne crée pas de session concerne projet, fournisseur, permissions ou modèle. Modifier tout en même temps détruit l’indice utile.

Avec un port fixe, vérifiez le processus à l’écoute et le même numéro dans l’URL imprimée. Avec un hostname réseau, testez d’abord localhost et le mot de passe, puis le second appareil. Avec mDNS, comparez le nom annoncé et l’adresse réelle.

Si une session surprend, sauvegardez commande, répertoire, ID de modèle, origine des variables et Git status. Reproduisez une petite requête en lecture puis un changement documentaire. Arrêtez-vous si le diff contient secrets, fichiers étrangers ou chemins hors worktree.

Choisissez Web lorsque le navigateur facilite la revue du projet et de la conversation, lorsque vous voulez une seconde vue du serveur ou une URL locale répétable. Le TUI reste préférable pour le clavier, le shell intensif ou un environnement sans navigateur.

Web ne remplace pas les guides fournisseur, permissions ou Docker : il change seulement l’accès au serveur. Identifiants, droits, montages, outils MCP et revue Git demandent toujours leurs contrôles. Liez la page étroite correspondant à la prochaine décision.

Une routine robuste est : démarrer en local, vérifier projet et modèle, mettre un mot de passe avant d’élargir le hostname, noter le port, attacher le TUI si besoin et arrêter le serveur à la fin. Un listener de développement ne devient pas ainsi un service public.