Développement à distance avec Zed : SSH, tâches et aperçus locaux

Imaginez transférer un petit projet web sur un hôte de développement existant. L’éditeur garde son apparence familière. Mais quelle machine exécute une tâche, et vers quoi pointe le localhost de votre navigateur ? Voilà les questions à régler avant de modifier les paramètres.

Le développement à distance avec Zed relie votre éditeur local à une copie de travail par SSH. L’interface reste sur votre ordinateur portable ; les serveurs de langage, les tâches et les terminaux s’exécutent sur l’hôte distant. La documentation de Zed sur le développement à distance explique cette répartition.

Les exemples ci-dessous sont des propositions fondées sur la documentation. Aucun n’a été exécuté pour cet article : aucune installation de Zed ni session SSH n’a été testée, et aucune application, aucun port ni appel à l’IA n’a été validé. Utilisez ce guide pour préparer une configuration et en examiner les limites.

Ce qui reste local et ce qui s’exécute sur l’hôte distant

Repérer les emplacements de l’éditeur, de la copie de travail et de l’exécution

Commencez par déterminer où le travail s’effectue. Une fenêtre d’apparence locale renseigne peu sur le processus qui se trouve derrière. L’architecture documentée attribue un emplacement à chaque composant :

Un hôte existant disposant des outils ou des données nécessaires à votre projet peut justifier le travail à distance. La connexion seule ne vous apporte ni un environnement reproductible ni la preuve de meilleures performances.

Examiner séparément le circuit des requêtes à l’IA

L’IA nécessite son propre examen. La présentation du développement à distance décrit une communication locale avec les modèles, tandis que la documentation de Zed sur la confidentialité de l’IA distingue les circuits de requêtes associés aux clés des fournisseurs, aux passerelles, aux agents externes et aux fils de discussion dans le terminal. L’emplacement de la copie de travail ne permet pas de déduire où une requête est envoyée.

Commencer avec un hôte autorisé et une copie de travail dédiée au développement

Confirmer l’accès SSH sans affaiblir la vérification

Ce guide suppose que vous disposez déjà d’un accès autorisé à un hôte de développement. Préparez sa chaîne d’outils séparément et choisissez une copie de travail dédiée, hors production. Le nom d’hôte devbox.example.com est fictif ; remplacez-le par votre hôte approuvé lors de la préparation de la connexion.

Dans la boîte de dialogue des projets distants de Zed, choisissez de connecter un nouveau serveur et renseignez la connexion SSH approuvée. Zed utilise votre exécutable SSH local et sa configuration ; sa documentation de connexion recommande l’authentification par clé pour les connexions répétées. Laissez la vérification de la clé d’hôte activée et suivez la procédure d’accès de votre organisation. Une erreur de connexion doit conduire à une investigation, jamais à placer des clés privées dans les paramètres du projet ni à désactiver la vérification.

Sélectionnez le dossier du projet lui-même. La même documentation déconseille d’ouvrir des répertoires racines trop volumineux, notamment la racine du système de fichiers ou un répertoire personnel entier.

Vérifier les prérequis du serveur distant et de la chaîne d’outils

L’hôte doit disposer d’un exécutable de serveur Zed correspondant à la version utilisée. La documentation sur le développement à distance répertorie les hôtes macOS, Linux et Windows en précisant certaines limites, notamment des tests non exhaustifs des distributions Linux. Lisez les exigences applicables à votre hôte avant de vous engager dans cette configuration.

Utilisez cette liste de préparation :

• Votre accès SSH approuvé fonctionne sans affaiblir la vérification.
• La plateforme distante peut exécuter le serveur Zed correspondant.
• La copie de travail dédiée et l’environnement d’exécution du projet existent déjà.
• L’exécutable du serveur dispose d’un moyen de téléchargement ou de transfert approuvé.

L’option documentée upload_binary_over_ssh télécharge l’exécutable du serveur localement, puis le transfère par SSH. Les dépendances du projet nécessitent toujours une préparation distincte, et cette option ne rend pas toutes les fonctionnalités disponibles hors ligne. La liste ci-dessus reste une proposition tant que vous ne l’avez pas vérifiée sur votre hôte.

Placer les paramètres et les vérifications de l’environnement d’exécution au bon endroit

Distinguer les paramètres locaux, du serveur et du projet

Une modification de paramètres n’est utile que si le processus concerné les lit. Les deux processus Zed lisent les paramètres du projet, mais aucun ne lit le fichier de paramètres principal de l’autre. La documentation des paramètres vous indique quelle portée choisir :

Gardez les chemins propres à une machine hors de la configuration partagée. Sinon, la prochaine personne qui ouvrira la copie de travail héritera d’une dépendance à votre système de fichiers.

Vérifier l’environnement d’exécution distant sans afficher toutes les variables d’environnement

Pour un projet Node.js sur un hôte de développement de type Unix, envisagez ces vérifications en lecture seule dans le terminal distant. Elles supposent un shell de type POSIX, l’utilitaire hostname disponible et un environnement d’exécution Node.js installé. Les exécuter dans un shell distinct sur l’ordinateur portable répondrait à la mauvaise question.

hostname
pwd
command -v node
node --version

Sans argument, hostname affiche le nom d’hôte ; pwd indique le répertoire de travail. command -v indique comment le shell résout une commande, ce qui peut désigner un alias ou une fonction plutôt que le chemin d’un exécutable. node --version affiche la version de Node.js. La référence de hostname décrit le comportement de la commande, pas la prise en charge d’OpenBSD par Zed.

Examinez les résultats en privé. L’hôte correspond-il à la machine prévue ? Le répertoire appartient-il à la copie de travail ? Comparez l’environnement d’exécution trouvé aux exigences du projet. Si la recherche de la commande échoue, résolvez ce problème avant de demander la version. Aucun résultat ni aucune version attendue ne sont affirmés ici, et il n’est pas nécessaire de partager des noms d’hôtes sensibles ni d’afficher l’ensemble des variables d’environnement.

Une réussite dans le terminal ne renseigne que sur le terminal. La documentation de Zed sur l’environnement décrit des traitements différents selon le lancement en ligne de commande ou par l’interface graphique, les tâches, les terminaux et la recherche des serveurs de langage. Vérifiez séparément la recherche des exécutables des serveurs de langage. Ne supposez pas que les variables ou les secrets de l’ordinateur portable sont transférés automatiquement.

Pour les projets de création de paquets Python, la liste de vérification de la construction et de la publication avec uv aborde une autre limite : une copie de travail fonctionnelle ne prouve pas que le paquet distribué fonctionne.

Faire utiliser aux tâches distantes le répertoire, le fichier enregistré et le contexte prévus

Choisir délibérément la portée des tâches et la politique d’enregistrement

Placez les tâches du projet dans .zed/tasks.json. Les tâches globales sont disponibles dans tous les projets. La documentation des tâches de Zed définit ces deux portées et fixe le répertoire de travail par défaut à la racine du projet courant.

Cette proposition de définition d’une tâche de projet affiche uniquement ce répertoire sur un hôte de type Unix :

[
  {
    "label": "inspect-task-directory",
    "command": "pwd",
    "save": "none"
  }
]

Écrire ce fichier modifie la configuration, même si pwd est une commande en lecture seule. L’exemple n’a été ni installé ni exécuté. Son libellé est un identifiant machine, et sa commande indique le répertoire de travail. Si vous ajoutez un cwd explicite pour un sous-projet, utilisez le répertoire distant prévu. Un chemin de l’ordinateur portable ne permettra pas de le désigner.

La valeur d’enregistrement par défaut mérite votre attention. Avec none, un tampon modifié peut différer du fichier lu par un outil. Choisissez current pour enregistrer le tampon actif ou all pour enregistrer tous les tampons modifiés, comme le précise la référence des tâches. Vérifiez quels fichiers ce choix modifierait avant de l’adopter.

Pour une tâche ultérieure utilisant un fichier, suivez la distinction entre command et args dans la documentation des tâches, notamment le traitement des variables dans les chemins contenant des espaces. Cet exemple avec pwd n’a aucun argument de fichier. Il ne vous renseigne pas sur l’entrée qu’un test lirait.

Distinguer le contexte de relance de la réutilisation du terminal

Sélectionner un autre fichier ne modifie pas nécessairement une relance. Par défaut, Zed réutilise le contexte résolu, y compris les variables de fichier précédemment capturées. L’exemple de contrôle de la relance place reevaluate_context sur l’action task::Rerun dans une association de touches. Il ne s’agit pas d’un champ du modèle de tâche.

La réutilisation du terminal contrôle autre chose. Les valeurs par défaut documentées réutilisent un terminal et attendent la fin de la tâche précédente. Un nouvel onglet ne sélectionnera pas un autre hôte ni un autre fichier. L’exécution simultanée ne résoudra pas non plus un décalage dans les entrées.

Avant d’exécuter la commande réelle du projet, examinez la copie de travail et le répertoire de travail, puis comparez l’entrée enregistrée au contexte résolu. L’affichage réussi d’un répertoire laisse les tests de l’application non vérifiés.

Suivre le trajet d’une application web distante jusqu’à son aperçu dans un navigateur sur localhost

Distinguer l’écoute de l’application de la redirection SSH

Pour un aperçu hypothétique, supposons que vous démarriez séparément une application de développement sur le port de bouclage 3000 de l’hôte distant. La configuration de cette application sort du cadre de ce guide. Sa procédure d’installation et de démarrage n’est ni fournie ni exécutée ici.

Cet extrait proposé associe le port local 8080 au port distant au moyen de la configuration documentée ssh_connections.port_forwards de Zed. Intégrez-le à la connexion de votre hôte autorisé en conservant le reste de votre liste de connexions.

{
  "ssh_connections": [
    {
      "host": "devbox.example.com",
      "port_forwards": [
        { "local_port": 8080, "remote_port": 3000 }
      ]
    }
  ]
}

Suivez le trajet prévu de la requête jusqu’à l’application déjà en cours d’exécution :

La redirection ne peut pas démarrer l’application. Si l’aperçu échoue, vérifiez d’abord si l’application est à l’écoute. Examinez ensuite le trajet de la redirection, y compris les conflits de ports locaux et la destination distante. La configuration d’un tunnel ne confirme pas que l’application est prête.

Garder l’aperçu lié à localhost

Les valeurs par défaut de redirection de Zed lient les deux extrémités à localhost. Conservez-les pour cet aperçu. Définir local_host sur 0.0.0.0 lie l’écoute à toutes les interfaces locales. Configurez la connexion et la redirection prévues avant de consulter http://localhost:8080 ; le localhost du navigateur désigne toujours votre ordinateur portable.

La liaison à l’interface de bouclage ne fournit ni authentification de l’application ni déploiement public. Une fois l’application prévue accessible, les tests d’accessibilité des états de l’interface avec Playwright constituent une tâche distincte de vérification de l’application. Accéder à l’aperçu ne prouve pas la réussite d’un test.

Utiliser la méthode Hôte-Tâche-Aperçu pour vérifier un projet de développement

Hôte-Tâche-Aperçu est la liste de vérification éditoriale proposée dans ce guide. Elle rassemble les limites documentées dans une matrice de décision ; ce n’est ni une fonctionnalité de Zed ni une norme du secteur, et elle n’a pas été testée comme méthode de déploiement.

Hôte : identifier la copie de travail et la portée de la configuration

Utilisez une seule copie de travail de développement sans données sensibles. Déterminez quel hôte et quelle portée de paramètres vous examinez avant de diagnostiquer l’application.

Tâche : examiner l’environnement d’exécution et l’entrée enregistrée

Lisez les entrées de la commande aussi attentivement que son libellé. Vérifiez le comportement du serveur de langage séparément des résultats du terminal.

Aperçu : vérifier l’écoute et le trajet depuis le navigateur

Suivez la requête jusqu’à trouver le premier décalage. Corrigez cette couche avant de modifier un autre paramètre.

Conservez quelques notes pendant l’essai. Ces observations aident à décider si la configuration convient ; elles ne mesurent pas un gain de performances.

Pour un relevé de planification lisible par machine, les mêmes limites peuvent être représentées comme suit. Son statut reste proposé et non exécuté.

{
  "framework": "host-task-preview",
  "checks": ["authorized-checkout", "saved-task-input", "running-app-and-local-forward"],
  "status": "proposed-unexecuted"
}

Avant d’ajouter des dépôts ou des données sensibles, assurez-vous de pouvoir expliquer chaque circuit et chaque limite d’accès. Gardez vos notes privées et omettez les identifiants de connexion ainsi que les relevés complets des variables d’environnement. Cet article ne consigne aucune liste de vérification achevée.

Erreurs courantes et limites : SSH n’est ni un bac à sable ni une politique de confidentialité de l’IA

Corriger l’hypothèse avant de modifier le paramètre

Soyez attentif à ces erreurs de diagnostic :

• Vérifier l’environnement d’exécution de l’ordinateur portable alors que la tâche s’exécute à distance.
• Ouvrir un répertoire personnel entier au lieu du projet.
• Supposer qu’une relance suit le fichier nouvellement sélectionné.
• S’attendre à ce que les modifications non enregistrées constituent l’entrée testée.
• Rediriger un port avant que l’application soit à l’écoute.

Chacune renvoie à une ligne précise de la matrice de décision. Utilisez-la pour isoler le problème.

Examiner séparément la confiance accordée aux copies de travail et le routage de l’IA

Zed conserve les informations de confiance des copies de travail séparément pour chaque hôte SSH. Le mode restreint empêche d’appliquer les paramètres du projet ainsi que d’installer ou de démarrer les serveurs de langage et MCP non approuvés qui leur sont associés ; les outils approuvés globalement peuvent toujours s’exécuter. Examinez la configuration et les instructions du projet, ainsi que les outils qu’il peut invoquer, avant de lui accorder votre confiance. Accorder une confiance générale est une mauvaise réponse à une question d’autorisation. La confiance accordée aux copies de travail ne constitue pas un bac à sable complet.

Pour l’IA, examinez le circuit de requêtes choisi et les conditions du fournisseur. Les agents externes et les outils en terminal peuvent gérer leur propre authentification, leur routage et leurs autorisations, comme l’expliquent les recommandations de Zed sur la confidentialité. Le transport SSH n’apporte aucune garantie universelle concernant la conservation, l’entraînement ou la confidentialité.

Si le circuit choisi comprend une passerelle, le guide Vercel AI Gateway propose une liste de vérification distincte du routage et de la politique des fournisseurs. Ce lien ne signifie pas que votre session Zed utilise cette passerelle. L’édition à distance de base ne nécessite aucun appel à l’IA ; le guide de démarrage rapide de l’IA dans Zed indique la commande de désactivation de l’IA dans l’éditeur de paramètres.

Savoir quand garder le projet en local

Le développement à distance doit justifier son coût de maintenance. Mettez en balance l’administration et la préparation de la chaîne d’outils avec le travail qu’elles vous permettent d’accomplir. Vérifiez aussi la prise en charge de la plateforme, la fiabilité de la connexion et la maintenance continue. Si vous activez l’IA, examinez le comportement du fournisseur et sa politique relative aux données. Les économies ou la réduction de la latence nécessitent des preuves issues de votre propre charge de travail.

Conservez vos pratiques habituelles d’enregistrement et de gestion de versions ; se reconnecter n’est pas une stratégie de sauvegarde. Si personne ne peut maintenir les limites d’accès de l’hôte, gardez le projet en local. Sinon, commencez par la plus petite copie de travail dont l’emplacement résout un problème de développement réel. Étendez l’usage après avoir compris ses circuits d’exécution et d’aperçu.