Le mécanisme
Ce que l’éditeur met sur le socket.
Un socket de domaine Unix en 0600, du JSON-RPC par-dessus, et une liste d’outils limitée à une fenêtre. Le même chemin de socket est exporté dans le panneau de terminal sous $LINELARK_MCP_SOCKET, donc un claude que vous lancez vous-même dans un shell reçoit les mêmes outils que le dock.
01Un serveur par fenêtre, pas un par app
Les outils répondent pour la fenêtre dont la session a appelé. La fenêtre au premier plan suit vos clics : un serveur valable pour toute l’app laisserait « l’onglet actif » dériver vers un fichier que la session qui demande n’a jamais vu.
02Il lit le tampon, pas le fichier
open_tabs, active_buffer, selection, read_lines et tail_lines répondent à partir du texte présent dans l’éditeur, modifications non enregistrées comprises. C’est la différence qui vaut la peine : le disque est une copie périmée de ce sur quoi vous travaillez vraiment.
03find_in_buffer est le moteur de la barre de recherche
Une recherche passe par FindEngine sur le tampon tel qu’il est tapé, plutôt que sur la dernière version écrite. C’est la raison d’interroger l’éditeur au lieu de lancer grep dans un shell.
04Les modifications arrivent en une seule annulation
replace_lines et insert_lines passent par la même session d’édition que les écritures d’un plugin, donc la modification d’un agent est une seule modification annulable qui atteint chaque volet affichant ce tampon. ⌘Z la retire, et vous décidez quand enregistrer.
05La carte d’approbation est aussi un outil MCP
Un agent sans interface n’a aucun terminal où demander : la demande d’autorisation de Claude Code est donc dirigée vers un outil à nous, et l’accord ou le refus est dessiné dans le dock — portant le diff que deviendrait le tampon plutôt que le nom de l’outil qui demande.
06Les lectures sont bornées et découpées
Chaque lecture prend une plage et a un plafond. Sans cela, un tampon de 40 Mo arrive entier dans une fenêtre de contexte.