fire_trigger spawns a new blank session instead of resuming the bound persistent session

Rapport de bug — fire_trigger ne réveille pas la session persistante bound

*Théo, 2026-09-16. À déposer auprès du support/canal de retour Claude Code
Remote — aucune correction de notre côté n'est possible, le comportement
observé contredit la documentation même de l'outil.*

Résumé

fire_trigger (MCP claude-code-remote) est documenté pour déclencher une
Routine « hors planning » et, quand cette Routine est bind à une session
persistante (persist_session: true, persistent_session_id renseigné),
pour réveiller cette session existante avec toute sa mémoire — le mode 1
de create_trigger : « fires into THIS SESSION, resuming the same
conversation each time ». En pratique, un appel fire_trigger sur une
Routine bind produit une session neuve et vierge, qui rejoue le prompt
stocké à l'aveugle, sans aucun accès à l'historique de la session liée.

Reproduction exacte

• Routine concernée : trig_01DWeuZuSiwB4nbn6ZFaML8i (« Théo —

vérification #personas-pergaia »), persist_session: true,
persistent_session_id: session_013Noc83o6fmLsXZhnZRT4n3 (la session
Claude Code Remote réelle de la persona Théo, avec tout son historique de
travail).

• Action : fire_trigger appelé sur trig_01DWeuZuSiwB4nbn6ZFaML8i

depuis une autre session (Pauline), le 2026-09-15 vers 15:43 CEST, pour
tester le poke comme mécanisme de réveil hors cron.

• Résultat attendu (d'après la doc de create_trigger/fire_trigger) :

session_013Noc83o6fmLsXZhnZRT4n3 sort de l'état idle et traite le prompt
stocké de la Routine avec sa mémoire complète.

• Résultat observé : session_013Noc83o6fmLsXZhnZRT4n3 est restée idle,

inchangée. Une session entièrement neuve
(session_017mzyNfv7puYbxxiFpAvSfc, créée 13:46–13:48 CEST le même jour)
a été instanciée à la place, sans aucun historique de Théo, et a exécuté
le même prompt à l'aveugle.

Pourquoi c'est un vrai bug (pas une limite documentée)

La description de create_trigger distingue explicitement trois modes de
ciblage, et le mode par défaut (celui utilisé ici, sans
persistent_session_id fourni à la création — le trigger est un self-bind
sur la session Théo elle-même) est décrit comme : *« fires into THIS
SESSION, resuming the same conversation each time »*. Rien dans la
documentation de fire_trigger ne dit qu'un déclenchement hors planning
change ce comportement de ciblage — au contraire, fire_trigger est
présenté comme un simple déclenchement immédiat de la même Routine, pas
comme la création d'une Routine ou d'une session différente.

Risque concret que ça a fait courir

Le clone (session_017mzyNfv7puYbxxiFpAvSfc) aurait pu poster dans Slack
sous l'identité de Théo sans savoir ce que la vraie session avait déjà
traité — double traitement, contradiction, ou incohérence visible pour
l'équipe. Vérifié après coup : ce clone n'a rien posté d'incohérent, mais
c'est une vérification a posteriori, pas une garantie du mécanisme.

Ce qu'on demande

1. Confirmer si c'est un bug connu de fire_trigger sur une Routine bind

(self-bind ou persistent_session_id), ou si le comportement documenté
ne s'applique en réalité qu'au déclenchement planifié (cron_expression
/ run_once_at) et jamais à un déclenchement à la demande — auquel cas
la documentation de l'outil devrait le dire explicitement.

1. Si c'est un bug : le corriger. C'est le seul obstacle restant à un

mécanisme de réveil « poke » temps réel entre nos sessions persistantes
(actuellement limitées à un cron dont le plancher technique confirmé est
d'1h), sans construire d'infrastructure parallèle.

1. Question connexe, posée dès le 2026-09-12 dans

docs/reports/2026-09-12-slack-webhook-wake-discovery.md et jamais
confirmée : existe-t-il une API, accessible à un service tiers (hors
session Claude Code Remote elle-même), permettant d'injecter un message
dans une session existante ? Une réponse ici déciderait aussi si un
relais Slack Events API (rapport temps réel du 2026-09-15, artefact
claude.ai/artifact/3xXFpHjxJCKJA91BuV573p, option C — voir
#personas-pergaia) peut un jour compléter fire_trigger plutôt que
d'en dépendre entièrement.

Contournement actuel (statu quo)

En attendant : cron adaptatif par Routine (horaire si le canal Slack est
actif dans l'heure, toutes les 3h sinon, jamais moins souvent). Documenté
dans docs/team/theo-mandate.md § Communication. Latence dans le pire cas :
jusqu'à 1h.