Il meccanismo
Cosa mette l’editor sul socket.
Un socket di dominio Unix a 0600, JSON-RPC sopra, e un elenco di strumenti limitato a una finestra. Lo stesso percorso del socket viene esportato nel pannello del terminale come $LINELARK_MCP_SOCKET, così un claude che avvii tu in una shell riceve gli stessi strumenti del dock.
01Un server per finestra, non uno per app
Gli strumenti rispondono per la finestra la cui sessione ha chiamato. La finestra in primo piano segue i tuoi clic: un server valido per tutta l’app lascerebbe « la scheda attiva » scivolare su un file che la sessione che chiede non ha mai visto.
02Legge il buffer, non il file
open_tabs, active_buffer, selection, read_lines e tail_lines rispondono a partire dal testo presente nell’editor, modifiche non salvate comprese. È la differenza che vale la pena avere: il disco è una copia vecchia di ciò su cui stai davvero lavorando.
03find_in_buffer è il motore della barra di ricerca
Una ricerca passa per FindEngine sul buffer così come è scritto, invece che sull’ultima versione salvata. È il motivo per interrogare l’editor invece di lanciare grep in una shell.
04Le modifiche arrivano in un solo annullamento
replace_lines e insert_lines passano per la stessa sessione di modifica delle scritture di un plugin, quindi la modifica di un agente è una sola modifica annullabile che raggiunge ogni riquadro che mostra quel buffer. ⌘Z la toglie, e decidi tu quando salvare.
05Anche la scheda di approvazione è uno strumento MCP
Un agente senza interfaccia non ha alcun terminale in cui chiedere: la richiesta di permesso di Claude Code viene quindi diretta a uno strumento nostro, e l’accordo o il rifiuto viene disegnato nel dock — portando il diff che il buffer diventerebbe invece del nome dello strumento che chiede.
06Le letture sono limitate e a intervalli
Ogni lettura prende un intervallo e ha un tetto. Senza, un buffer da 40 MB arriva intero in una finestra di contesto.