diff --git a/hermes-nyora/dsh-vps-defaultpreset-fix.md b/hermes-nyora/dsh-vps-defaultpreset-fix.md
new file mode 100644
index 0000000..fef5f42
--- /dev/null
+++ b/hermes-nyora/dsh-vps-defaultpreset-fix.md
@@ -0,0 +1,70 @@
+# DSH VPS — defaultPreset danger-full-access par défaut + piège `docker compose up -d`
+
+**Instance auteur** : hermes-nyora (vérification) + Claude (exécution, correctif ponctuel)
+**Date** : 2026-08-24
+**Tags** : dsh, vps-contabo, docker, permissions, securite
+**Statut** : clos, vérifié en direct après redémarrage
+
+---
+
+## Problème
+
+`permission.defaultPreset` dans `$DSH_HOME/settings.yaml` était sur `danger-full-access` (accès fichiers complet, aucune approbation) — valeur héritée du premier déploiement, jamais durcie. Toute nouvelle session dsh-vps héritait de ce défaut, y compris une éventuelle session `cordis` (auto-modification du runtime) ouverte sans intervention manuelle. Seule la session active de Nabil avait été basculée à la main sur `workspace-write` via l'UI — le défaut global, lui, restait dangereux.
+
+---
+
+## Ce qui a été vérifié avant d'agir (pas supposé)
+
+- **Piège potentiel identifié par hermes-nyora avant validation** : `entrypoint.sh` pourrait-il re-scaffolder `settings.yaml` à chaque boot et écraser le fix (même bug que le SKILL.md `session-memory` mort) ? Vérifié : le bloc d'écriture est gardé par `if [ ! -f "$DSH_HOME/settings.yaml" ]` — le fichier existe déjà dans le volume nommé `dsh_vps_home`, ce bloc ne s'exécute donc jamais au redémarrage. Le fix tient.
+- **Valeur littérale exacte** : vérifiée dans le JS compilé de `@deepseek-ai/dsh-permission-presets` (pas dans la doc) — la table de presets par défaut du module contient exactement `"workspace-write": { sandbox: "workspace-write", approval: "ask" }`. Orthographe confirmée avant application.
+
+---
+
+## Piège technique dans la procédure initiale
+
+`docker compose up -d dsh-vps` ne recharge PAS un conteneur déjà démarré dont seul le contenu d'un volume monté a changé (aucun changement du côté image/compose/env) — la commande est un no-op dans ce cas précis. Il faut `docker compose restart dsh-vps` pour que le process relise `settings.yaml` au démarrage.
+
+---
+
+## Solution appliquée
+
+```bash
+# Backup (le fichier vit dans un volume nommé, pas un bind mount — passer par docker exec)
+sudo docker exec dsh-vps sh -c "cp \$DSH_HOME/settings.yaml \$DSH_HOME/settings.yaml.bak-defaultpreset-20260824"
+
+# Modification
+sudo docker exec dsh-vps sh -c 'sed -i "s/defaultPreset: danger-full-access/defaultPreset: workspace-write/" $DSH_HOME/settings.yaml'
+
+# Rechargement correct (pas up -d)
+cd /home/dsh-agent/dsh-vps && sudo docker compose restart dsh-vps
+```
+
+---
+
+## Vérification
+
+```bash
+docker exec dsh-vps sh -c 'grep -A1 "^permission:" $DSH_HOME/settings.yaml'
+# attendu, APRÈS redémarrage : defaultPreset: workspace-write (persistant, pas juste avant restart)
+
+docker ps --filter name=dsh-vps --format "{{.Status}}"
+# attendu : Up, pas de crash loop
+
+curl -sk -o /dev/null -w "%{http_code}\n" https://<tailscale-ip>:8900/
+# attendu : 401 (proxy + service toujours sains)
+```
+
+Résultat réel : `workspace-write` confirmé après redémarrage, conteneur up, proxy toujours en 401 — rien de cassé.
+
+---
+
+## Leçon générale, transverse à tout déploiement DSH
+
+Toujours vérifier `permission.defaultPreset` après un premier déploiement — le défaut du produit n'est pas nécessairement le défaut souhaité pour une instance exposée. Et pour toute modification d'un fichier vivant dans un volume nommé (pas un bind mount visible côté host) : `docker compose restart <service>`, jamais `up -d`, si rien d'autre n'a changé dans le compose/l'image.
+
+---
+
+## Références
+
+- Runbook associé : `hermes-nyora/dsh-vps-pnpm-plugins-bloques.md`
+- Note NyoraNotes : `dsh/dsh-vps-audit-capacite-plugins-mcp-et-memoire-persistante.md`, `dsh/dsh-vps-bridge-mcp-context-hub-verifie-fonctionnel-isolation-testee.md`