Partager une session OpenCode en sécurité et révoquer le lien

Avant d’envoyer une session OpenCode à un collègue, considérez le lien comme une petite publication publique, et non comme une invitation privée destinée à une seule personne. La documentation d’OpenCode indique qu’une conversation partagée est accessible à toute personne qui possède l’URL. Pour la plupart des équipes, la méthode sûre consiste à relire toute la session, à la partager en mode manual, puis à exécuter /unshare dès la fin de la collaboration. Pour un projet sensible, préférez disabled.

Ce qu’un lien de partage OpenCode rend public

Le lien ne montre pas uniquement la dernière réponse que vous souhaitez commenter. Selon la documentation officielle OpenCode Share, le partage crée une URL publique unique, synchronise l’historique avec les serveurs d’OpenCode et rend accessibles :

• l’historique complet de la conversation ;
• tous les messages et toutes les réponses ;
• les métadonnées de la session.

Cela ne signifie pas qu’OpenCode publie automatiquement tout votre dépôt local. Le risque concret est que du code source, une configuration, des journaux, une sortie de commande ou le contenu d’un fichier font partie de l’historique partagé dès qu’ils apparaissent dans un message ou une réponse. Le lien standard n’est pas non plus limité au collègue auquel vous l’envoyez : toute personne qui obtient l’URL peut l’ouvrir.

La session reste accessible jusqu’à ce que vous annuliez explicitement son partage. Ne vérifiez donc pas seulement les derniers messages et ne prenez pas une URL difficile à deviner pour un véritable contrôle d’accès.

Choisir entre manual, auto et disabled

Dans un usage courant, choisissez entre manual et disabled. N’utilisez auto que si vous acceptez volontairement que chaque nouvelle conversation soit partagée avant toute revue humaine.

Mode	Fonctionnement	Cas adapté	Risque principal
manual	Mode par défaut ; le lien est créé uniquement après /share	Collaboration occasionnelle autour d’une session déjà vérifiée	Une revue peut manquer un détail, mais les nouvelles sessions ne sont pas publiées automatiquement
auto	Chaque nouvelle conversation est partagée et reçoit un lien	Flux conçu pour être public	Secrets, code ou journaux peuvent être publiés avant vérification
disabled	Désactive complètement le partage	Dépôts privés, données clients, environnement réglementé ou équipe sans besoin de lien public	Il faut utiliser un autre moyen de collaboration contrôlé

La règle est simple : manual pour montrer ponctuellement une session vérifiée ; disabled si le projet est sensible, si les liens publics sont inutiles ou si l’équipe ne peut pas garantir une revue rigoureuse. N’activez pas auto uniquement pour éviter de saisir /share.

Examiner toute la session avant de la partager

Relisez du premier au dernier message. La page publique contient l’historique complet ; nettoyer seulement l’extrait que vous comptez coller dans la messagerie de l’équipe ne suffit pas. Si une information sensible reste dans la session d’origine, ne partagez pas cette session.

1. Identifiants et données d’authentification

Recherchez les clés API, jetons d’accès, mots de passe, clés privées, cookies, jetons de session, en-têtes Authorization, chaînes de connexion, URL signées et valeurs réelles copiées depuis des fichiers .env. Les noms de variables et les valeurs fictives peuvent être sans danger ; les valeurs actives ne le sont pas.

Si un identifiant apparaît déjà dans l’historique et que vous ne pouvez pas confirmer sa suppression, révoquez-le ou renouvelez-le, créez une session propre sans le secret et partagez uniquement cette nouvelle session.

2. Code propriétaire et contexte métier

Vérifiez les fichiers source, correctifs, configurations, requêtes SQL, notes d’architecture, noms de clients, exigences internes et fonctions non publiées que le modèle a lus ou produits. Plusieurs fragments apparemment anodins peuvent, ensemble, révéler l’architecture du système, la logique métier ou les limites de sécurité.

3. Journaux et sorties de commandes

Les journaux et erreurs contiennent souvent des chemins locaux, noms d’utilisateur, adresses e-mail, noms d’hôte, domaines internes, adresses IP, noms de dépôt et de branche, numéros de ticket, bases de données ou paramètres de requête. Ne cherchez pas seulement token et password : examinez les traces de pile, résultats de tests, journaux CI, git diff, commandes curl et sorties du terminal.

4. Métadonnées et éléments identifiants

OpenCode cite explicitement les métadonnées de session parmi les données partagées. Vérifiez le nom du projet et de la session, les branches, les chemins de fichiers et tout détail susceptible d’identifier une organisation ou un système interne.

5. Si le nettoyage n’est pas fiable, créer une session propre

La documentation publique ne promet pas de masquage automatique. Ne supposez pas qu’OpenCode cachera les identifiants et ne partagez pas « pour voir ce qui apparaît ». Recréez dans une nouvelle conversation le minimum de code, d’erreur et de contexte nécessaire à la collaboration ; c’est généralement plus fiable que d’essayer de prouver qu’une longue session ne contient plus aucune donnée sensible.

Partager en toute sécurité avec le mode manual

manual est le mode par défaut et celui qui convient le mieux à une logique « vérifier, puis publier ».

Étape 1 : confirmer la valeur effective de share

OpenCode fusionne les configurations de plusieurs emplacements ; lorsqu’une même clé entre en conflit, la source chargée plus tard remplace la précédente. La configuration globale se trouve généralement dans ~/.config/opencode/opencode.json, et celle du projet dans opencode.json à la racine du dépôt. Exécutez :

opencode debug config

Dans la configuration résolue, vérifiez que share vaut réellement manual, et non auto provenant d’une autre source. Les emplacements et l’ordre de priorité sont décrits dans la documentation officielle OpenCode Config.

Pour définir explicitement le mode manuel, ajoutez ceci au fichier opencode.json approprié :

{
  "$schema": "https://opencode.ai/config.json",
  "share": "manual"
}

Étape 2 : terminer la vérification de confidentialité

Appliquez la liste précédente à tout l’historique. Si un identifiant, du code propriétaire, un journal confidentiel ou une métadonnée identifiable ne peut pas être publié, arrêtez-vous. Créez une nouvelle session minimale si la collaboration doit continuer.

Étape 3 : exécuter /share dans la session vérifiée

/share

La documentation officielle indique que la commande génère une URL unique et la copie dans le presse-papiers. Ne la transmettez pas immédiatement : examinez d’abord la page publique.

Étape 4 : ouvrir le lien comme le ferait le destinataire

Ouvrez l’URL dans une fenêtre privée ou un navigateur déconnecté et parcourez la page du début à la fin. Assurez-vous d’accepter que toute personne obtenant le lien voie l’intégralité du contenu, y compris les anciens messages et les longs journaux.

Cette vérification n’ajoute aucune autorisation. Le lien standard reste public.

Étape 5 : utiliser un canal contrôlé et fixer la date de révocation

Envoyez l’URL uniquement dans le canal d’équipe qui en a besoin et demandez de ne pas la transférer. Cette consigne réduit la diffusion accidentelle, mais ne lie pas techniquement le lien aux destinataires. Décidez dès le partage quand vous le révoquerez : à la résolution du bug, à la fin de la revue ou à l’expiration d’un délai défini.

Désactiver complètement le partage pour un projet sensible

Si le projet contient des données clients, des identifiants de production, du code propriétaire ou n’a aucun besoin légitime de liens publics, disabled est plus fiable que de dépendre de la mémoire de chaque contributeur.

Ajoutez ceci au fichier opencode.json à la racine du projet et validez-le dans Git :

{
  "$schema": "https://opencode.ai/config.json",
  "share": "disabled"
}

La documentation Share recommande une configuration de projet pour appliquer ce choix à l’équipe. Puisque les sources sont fusionnées, exécutez tout de même opencode debug config et contrôlez la valeur finale, surtout si une configuration inline ou administrée peut l’emporter.

Pour une politique d’organisation que les utilisateurs ordinaires ne peuvent pas modifier, les administrateurs doivent utiliser les managed settings. La documentation actuelle indique /Library/Application Support/opencode/ sur macOS, /etc/opencode/ sur Linux et %ProgramData%\opencode sous Windows ; ces paramètres ont une priorité supérieure aux fichiers utilisateur et projet. Les déploiements Enterprise peuvent également limiter l’accès aux utilisateurs authentifiés par SSO ou auto-héberger la fonction.

Révoquer un lien déjà partagé

La révocation est une action explicite. Fermer le terminal, supprimer le message contenant l’URL ou vider le presse-papiers ne retire pas une session déjà publique.

Étape 1 : revenir à la session d’origine et exécuter /unshare

/unshare

OpenCode indique que cette commande supprime l’accès public et le lien, puis efface les données associées à la conversation partagée.

Étape 2 : vérifier l’ancienne URL depuis l’extérieur

Conservez l’URL d’origine et ouvrez-la de nouveau dans une fenêtre privée ou un autre navigateur. Le véritable signe de réussite est que l’ancienne adresse n’affiche plus la conversation, pas seulement que la commande se termine sans erreur visible. Si le contenu reste disponible, vérifiez que vous avez annulé le partage de la bonne session et contrôlez l’état du client.

Étape 3 : si la vérification échoue, considérer le lien comme toujours public

La page Share publique actuelle documente /unshare depuis la conversation d’origine et ne présente pas de tableau de bord public séparé pour gérer les liens. Si vous ne pouvez pas retrouver la session, si la commande n’est pas disponible ou si l’ancienne URL affiche encore les données, n’annoncez pas que le lien est révoqué. Traitez-le comme public et contactez l’administrateur OpenCode ou le support jusqu’à ce qu’un contrôle externe confirme la disparition de l’accès.

Ce que /unshare ne peut pas récupérer

/unshare empêche OpenCode de continuer à servir la conversation à l’ancienne URL. La commande ne peut pas faire oublier ce qu’un destinataire a vu ni récupérer les captures d’écran, le code copié ou les journaux téléchargés auparavant.

La page officielle indique que les données liées au partage sont supprimées, mais elle ne promet pas d’effacer les caches de tiers, les copies du navigateur ou les archives créées par les destinataires. La révocation est donc un nettoyage nécessaire, pas un remplacement de la revue préalable. Si un identifiant actif a été exposé, révoquez-le ou renouvelez-le en plus d’exécuter /unshare.

Questions fréquentes

Le lien publie-t-il tout mon dépôt local ?

La documentation mentionne l’historique, les messages, les réponses et les métadonnées ; elle ne dit pas que tous les fichiers locaux sont publiés automatiquement. Toutefois, tout code, contenu de fichier, correctif ou journal entré dans la conversation doit être considéré comme partagé.

Puis-je autoriser une seule personne ?

La fonction standard est décrite comme un lien public accessible à toute personne qui possède l’URL, et non comme une liste d’autorisations par e-mail. Les organisations qui exigent une identité doivent étudier les options Enterprise documentées, telles que l’accès SSO ou l’auto-hébergement.

Pourquoi un lien est-il apparu sans /share ?

Vérifiez si la valeur résolue de share est auto. Exécutez opencode debug config, puis inspectez les sources globale, projet, inline et administrée pour identifier celle qui l’emporte.

Que faire si /share n’est pas disponible ?

Vérifiez si la valeur finale est disabled ou verrouillée par une politique administrée. Ne contournez pas une règle d’équipe avec un fichier de priorité inférieure ; demandez à l’administrateur quelle méthode de collaboration est autorisée.

Liste finale avant l’envoi

Avant d’envoyer l’URL, confirmez que :

• le mode effectif est manual, ou que le projet est volontairement en disabled ;
• vous avez relu l’historique depuis le premier message ;
• aucun identifiant actif, URL interne, code propriétaire, donnée client ou journal sensible ne subsiste ;
• vous avez ouvert la page publique dans une fenêtre déconnectée ;
• vous savez qui a besoin du lien, par quel canal l’envoyer et quand le révoquer ;
• après la collaboration, vous exécuterez /unshare dans la session d’origine et vérifierez l’ancienne URL.

En traitant le partage d’une session comme une publication plutôt que comme une simple pièce jointe de messagerie, vous verrez plus facilement les risques avant que le lien ne quitte vos mains.