docs: correction - alerte Telegram MCP-level deja active, pas de gap

hermes-nyora/vps-contabo-acces-claude-supervision.md

@@ -39,13 +39,14 @@ aucun agent n'a de sudo). Fichier `/etc/sudoers.d/claude-oversight-full`,
 valide par `visudo -c` avant activation. Verifie : `sudo -n whoami` -> root,
 lecture `/etc/shadow` reussie.
 
-**Gap de securite trouve en verifiant** : le garde-fou d'alerte Telegram
+**Fausse alerte corrigee (30/07/2026, meme session)** : le script
-original (`/etc/profile.d/claude-oversight-login-alert.sh`, toujours present)
+`/etc/profile.d/claude-oversight-login-alert.sh` (SSH interactif host-level)
-ne couvre QUE les sessions interactives (`[ -t 0 ]`) -- et de toute facon
+ne couvre effectivement pas `ssh host "commande"` non-interactif -- mais ce
-`/etc/profile.d/` n'est pas source du tout pour `ssh host "commande"`
+n'est PAS un gap, une autre couche d'alerte existe deja et couvre ce cas :
-non-interactif, qui est exactement le mode d'usage de mcp-vps:run_command.
+le **serveur MCP mcp-vps lui-meme** envoie une alerte Telegram (bot
-**L'usage routinier via mcp-vps ne declenche donc aucune alerte actuellement**,
+HermesPerso_bot) a chaque nouvelle session MCP ("nouvelle session MCP depuis
-contrairement a l'intention originale ("connexion toujours visible, jamais
+<IP> (Claude-User)") -- confirme par Nabil, alerte recue a 16h52 le 30/07.
-silencieuse"). Pas corrige a ce stade -- pose comme question ouverte a Nabil
+Granularite par session (pas par commande individuelle), ce qui est le bon
-(cf session Claude du 30/07) plutot que decide unilateralement, le
+niveau -- une alerte par run_command aurait ete du bruit permanent. Rien a
-compromis bruit-Telegram-par-commande-vs-visibilite etant un vrai arbitrage.
+corriger ; la transparence "jamais d'intervention silencieuse" est deja
+assuree, juste a une couche differente de celle initialement inspectee.