54a93e7c10
On a Windows Server CLI install, the console kept logging "Managed plugin bundle differs from its digest" and the browser filled with identical "questions and permissions not fully recovered" toasts, covering a phone's whole screen (#1235). The published package was correct. A bundled plugin file is named by its sha256 in a folder shared by every connection using the same OpenCode configuration, and it was written in place with writeFile(..., "wx"). A concurrent installer could read it half-written, and a write interrupted by stopping the server left a truncated file that "wx" never replaced, so every later connection failed. Both modes were reproduced with the published code and the exact reported error. A payload is now published only by renaming a complete temporary copy over its name. A file with the wrong bytes or a link is replaced the same way; a Windows directory link is re-checked and removed with rmdir, which never touches its target or a regular file, and a changed entry is re-verified instead of replaced, so one installer never deletes another's verified repair. An ordinary directory at that name is refused with a clear error. Verification and replacement share one bounded retry with backoff (about 3 s) for EPERM, EBUSY and EACCES locks from antivirus or readers. Each distinct failure (error code, operation and path, with only generated temporary names masked) is logged once as an actionable error; repeats go to debug until provisioning succeeds. In the UI, each recovery warning is shown at most once per project and message per tab, across reconnects, re-added projects and reloads, and a successful recovery re-arms it. The plugin-unavailable case is one plain notice, "Some waiting questions may be missing", saying that requests already waiting may not appear, new ones still do, and restarting CodeNomad may fix it. Toasts fit narrow screens. Strings, the permissions help page and NATIVE_INTERRUPTION_UX.md / OPENCODE_COMPATIBILITY.md are updated in all ten locales where applicable. Tests: installation regressions for wrong bytes, truncation, concurrent installers, file and directory links, a reader-held lock, an ordinary directory and a replayed concurrent-repair race; log dedupe across random temporary names and UUID-named directories; a store test with the real notification code (one notice after eight reconnects and a second project, nine before). Server plugin suites, UI recovery suites, both typechecks and the help checks pass. Fixes #1235
9.2 KiB
Questions et autorisations
Les questions, Forms et demandes d’autorisation natives se traitent dans le dock d’interruption juste au-dessus de la zone de saisie, pas dans les cartes d’outils en attente de la transcription.
Trouver la demande et vérifier sa source
- Sélectionnez une conversation avec Entrée requise / Autorisation requise, ou cliquez sur le badge de demande du projet pour ouvrir le dock sur place.
- Lisez le type de demande, le titre de conversation et la provenance avant de développer ou de répondre.
- Si plusieurs demandes attendent, utilisez Demande précédente / Demande suivante. Utilisez Voir la conversation seulement pour naviguer vers sa source.
| Provenance | Sens et comportement |
|---|---|
| Conversation ouverte | Sa demande peut se développer normalement |
| Sous-agent, avec parent Depuis … | Un descendant récursif de la conversation ouverte relève du contexte local ; la provenance du parent reste visible |
| Autre conversation | Commence par un aperçu compact ; développez explicitement pour répondre sans quitter la conversation actuelle |
| Demande de projet / de service | Un Form peut ne pas avoir de conversation propriétaire ; aucun lien de conversation inventé n’est affiché |
Les arrivées ne remplacent pas la demande en cours d’édition et ne vous font pas naviguer ailleurs. La sélection reste sur la même demande pendant les actualisations de file ; les flèches ne bouclent pas aux extrémités. Après règlement, la demande d’une autre conversation sans rapport reste compacte jusqu’à son ouverture.
Replier les demandes masque le corps ; cela ne refuse, n’annule et ne répond à rien. Un éditeur développé réduit temporairement la zone de saisie à sa hauteur minimale sans changer sa taille enregistrée ni son brouillon. Son contenu défile indépendamment des actions de réponse fixes.
Répondre aux questions et Forms
- Développez la demande voulue et remplissez ses champs ou sélectionnez les choix proposés.
- Lorsqu’un champ de choix autorise les réponses personnalisées, un champ de texte supplémentaire s’affiche : saisissez-y votre propre réponse à la place d’un choix proposé (ou ajoutez des valeurs personnalisées pour un champ à choix multiples). Répondez à chaque question obligatoire.
- Choisissez Envoyer ; n’utilisez Annuler pour une question ou un Form que si vous souhaitez cette annulation native.
Les réponses partielles et brouillons de refus survivent aux actualisations de file et à la navigation entre conversations dans le client actif. Ce ne sont ni une décision soumise ni une garantie de récupération après effacement des données du client. Une réponse échouée reste modifiable ; inspectez la demande en attente avant de réessayer. CodeNomad ne rejoue pas automatiquement une réponse.
Certains Forms proposent Ouvrir le formulaire externe pour un parcours navigateur. Suivez les instructions puis revenez à son statut, sans considérer une page ouverte comme une réponse réussie. Les Forms arbitraires de fournisseur/d’authentification ne sont pas nécessairement des éléments de conversation.
Les outils de question natifs terminés montrent dans l’historique la question, la réponse sélectionnée, les descriptions d’options et le texte personnalisé exact. Autres choix garde les autres choix accessibles. Ces résultats terminés sont distincts du dock actif.
Autoriser ou refuser une permission
- Lisez l’opération, les ressources et l’éventuel Diff demandé. Vérifiez quelle conversation recevra la décision.
- Saisissez éventuellement un commentaire expliquant un refus ou une solution plus sûre.
- Choisissez Autoriser une fois, Toujours autoriser ou Refuser.
| Choix | Effet natif | Limite de sécurité |
|---|---|---|
| Autoriser une fois | Approuve cette demande d’autorisation | Pas une approbation globale d’opérations futures sans rapport |
| Toujours autoriser | Envoie le choix natif d’approbation persistante des demandes correspondantes dans le contexte de session applicable | Pas un commutateur de confiance pour tout CodeNomad ou tout le système ; vérifiez la ressource/le motif autorisé |
| Refuser | Rejette la demande, avec commentaire facultatif | N’annule pas le travail effectué avant cette demande |
L’approbation peut déclencher immédiatement l’exécution d’un outil. Ce n’est pas une simulation. Les limites de diff/lecture et les contrôles d’identité de source peuvent empêcher une approbation si le contenu demandé ne peut pas être validé ; actualisez et examinez la demande réelle plutôt que d’approuver par supposition une autre opération.
Si un autre client règle une demande, elle peut disparaître ici. Un délai dépassé ou une réponse échouée ne prouve pas si le service natif a accepté la décision : laissez la réconciliation des demandes actualiser le dock avant de faire un autre choix délibéré. Une réponse ambiguë n’est jamais affichée comme une décision confirmée inventée.
Lire les reçus d’autorisation
- Cherchez Décisions d’autorisation à côté du contenu de transcription associé, même si les cartes d’outils natives sont masquées.
- Pour les décisions sans message source, ouvrez Décisions d’autorisation de la session.
- Utilisez Charger d’autres décisions pour continuer, ou Réessayer après un échec de lecture.
Les reçus enregistrent les demandes/ressources connues, la décision confirmée et le motif/la provenance disponible. Décision dans CodeNomad, Automatique · Yolo et Décision native distinguent les origines observées ; un règlement natif ne prouve pas un clic utilisateur dans cette fenêtre.
Les reçus sont des annotations CodeNomad en lecture seule, pas des messages natifs ou des éditeurs de règles d’autorisation. Ils sont exclus de la recherche native dans tout l’historique, de la copie des messages et de l’export. Ils ne peuvent pas reconstruire les décisions manquées quand CodeNomad était hors ligne, et un résultat d’outil réussi ne remplace pas un reçu manquant. Supprimer une session retire ses reçus.
Mode Yolo et portée familiale
- Sélectionnez une conversation et ouvrez Statut → Mode yolo.
- Activez-le uniquement si l’approbation automatique des autorisations convient à toute la famille.
- Désactivez-le avant d’autres travaux non fiables ; vérifiez les demandes en attente et les outils déjà actifs.
Même si la commande parle d’une session, sa portée effective est la racine de famille résolue et ses descendants : l’activer/le désactiver depuis un enfant affecte cette famille. Une bifurcation native est traitée comme sa propre racine. Ce n’est pas une approbation globale de tous les projets ou conversations indépendantes.
Yolo approuve uniquement les autorisations. Il ne répond pas aux questions ou Forms, ne fournit pas les informations manquantes, ne garantit pas le succès et ne contourne pas les contrôles de propriété du backend. Le backend CodeNomad effectue l’approbation automatique : fermer une fenêtre ne suffit pas à la désactiver si le backend reste actif, et un backend arrêté ne peut pas continuer à approuver. Le réglage familial est enregistré et restauré au prochain chargement de l’espace de travail.
Désactiver Yolo ne révoque pas une décision déjà acceptée et n’annule pas les effets sur les fichiers/le réseau. Vérifiez les reçus Automatique · Yolo et arrêtez explicitement l’exécution au besoin. Pour l’automatisation avec validations humaines, voir Missions.
Récupérer les demandes manquantes ou périmées
- Vérifiez l’indicateur de connexion et reconnectez-vous au même backend/projet.
- Laissez la récupération réconcilier les demandes natives en attente ; les demandes connues et brouillons restent conservés si la couverture est incomplète.
- Si l’avertissement récupération incomplète des questions et permissions apparaît, il indique le projet, la cause, les dossiers et les sessions concernés. Corrigez cette cause (par exemple un worktree supprimé, ou une session qui travaille hors de ce projet) ; le passage de récupération suivant réessaie automatiquement. Chaque avertissement n'apparaît qu'une fois par projet, même après une reconnexion ou un rechargement de la page. Si Des questions en attente peuvent manquer apparaît à la place, CodeNomad n'a pas pu joindre son plugin dans OpenCode : les nouvelles demandes s'affichent toujours, et redémarrer CodeNomad peut corriger le problème ; le journal du serveur en indique la cause.
La récupération ne charge pas tous les worktrees inactifs pour énumérer les demandes. Une réponse incomplète n’est pas une file vide faisant autorité, et l’avertissement n’autorise pas à répéter un prompt, une réponse ou une approbation. Recharger la configuration peut annuler des Forms/autorisations natifs ; ne l’utilisez pas comme bouton d’actualisation habituel des demandes. Voir Dépannage et Configuration d’OpenCode.