CodeSurf : un IDE spatial sur canvas pour piloter code, terminal et agents IA

https://github.com/jasonkneen/codesurf

📌 CodeSurf transforme un poste de travail en un grand canvas où terminal, chat, éditeur, navigateur et notes cohabitent, avec un état de projet persistant et des extensions pour bricoler son propre « context IDE ».

L’idée est simple : au lieu d’empiler des onglets et des fenêtres, tout devient des blocs que l’on pose et que l’on réorganise. Un bloc peut être un terminal, une conversation, un éditeur de code, un navigateur, une liste de fichiers, un tableau ou une note. On passe d’une vue libre (spatiale) à des dispositions plus structurées (onglets et layouts) quand il faut se concentrer, comparer deux fichiers, ou garder un plan de travail stable.

Dans la pratique, ce type d’outil sert quand un sujet déborde rapidement : débogage avec plusieurs commandes, lecture de docs, prise de notes, exploration d’un repo, puis échange avec un agent IA. Plutôt que de “perdre le contexte” en changeant d’application, l’espace de travail reste au même endroit et se rouvre tel quel. Les blocs deviennent des repères : une zone pour l’exploration, une zone pour les actions, une zone pour les décisions, une zone pour les résultats.

CodeSurf est une application desktop Electron. Les données de l’app sont stockées localement sous un dossier dédié dans le home (par défaut sous ~/.codesurf), avec des workspaces gérés comme des fichiers. Il est donc possible de travailler hors-ligne sur l’organisation du canvas, et de garder un historique de ce qui a été mis en place pour un projet. Comme l’état est local et basé sur des fichiers, le sujet “confidentialité” est surtout une question de ce qui est envoyé à des services externes par les blocs utilisés (par exemple une intégration de chat) plutôt que du canvas lui-même.

Le côté “context IDE” prend tout son sens avec des agents. Au lieu d’avoir un chat isolé, on peut imaginer une zone dédiée : une conversation liée au projet, un terminal déjà positionné dans le bon dossier, un navigateur ouvert sur la doc pertinente, et des notes qui résument les contraintes. À chaque nouvelle session, le point de départ est prêt. Pour du travail itératif (corriger, relancer, comparer, valider), c’est un gain net, surtout quand les tâches demandent de naviguer entre de multiples artefacts.

Au milieu, la différence est l’ergonomie : tout est pensé pour être manipulé comme une maquette de travail. On peut rapprocher deux blocs pour comparer, dupliquer une zone pour tester une variante, ou garder un bloc “référence” toujours visible. Quand un agent propose une piste, il devient plus facile de créer immédiatement l’espace pour l’évaluer : commandes à exécuter, fichiers à ouvrir, résultats à noter, liens à vérifier.

Points clés

• 🧩 Canvas infini pour organiser des blocs (terminal, chat, code, web, notes)
• 🗂️ Vues en onglets et layouts pour passer du spatial au structuré
• 🔌 Système d’extensions pour ajouter des blocs/outils sur mesure
• 🧠 État de workspace persistant, pensé pour conserver le contexte de projet
• 🧰 Outillage local possible via un serveur MCP, utile pour des workflows d’agents
• 🖥️ Application desktop Electron, stack moderne (React, TypeScript, Vite)

Pour démarrer côté usage, l’approche la plus efficace est de partir d’un projet concret et de construire un “poste de pilotage” minimal. Un terminal pointé sur le repo, un éditeur sur les fichiers chauds, un navigateur sur la documentation, et une note qui liste les objectifs et les contraintes. Ensuite, ajouter progressivement des blocs : une seconde console pour les logs, un tableau pour les tâches, un espace dédié aux décisions, et éventuellement une zone dédiée aux échanges avec un agent.

Côté exécution, le projet se lance comme beaucoup d’apps Electron modernes : installation des dépendances puis un mode dev. La stack repose sur React et TypeScript, avec Vite/electron-vite, Tailwind pour l’UI, xterm et node-pty pour le terminal, et Monaco pour l’édition. Cela donne une bonne base pour personnaliser l’app si besoin, ou au minimum pour comprendre où brancher une extension.

Pour un usage quotidien, les scénarios les plus parlants sont ceux où l’on fait beaucoup d’aller-retour : revue de code assistée par IA, préparation d’une PR, tri d’issues, ou investigation d’un bug intermittent. Le canvas sert alors de “mémoire de travail” : on garde visibles les éléments importants (logs, commandes, fichiers, explications), on documente au fil de l’eau, et on évite de reconstituer le puzzle à chaque reprise.

Sur la partie compatibilité modèles/écosystème, l’intérêt est de ne pas être prisonnier d’un seul chat : l’app peut accueillir différents blocs et intégrer des outils locaux. Le point à vérifier est la manière dont chaque bloc de chat se connecte à un fournisseur (clé API, proxy, local LLM), et ce qui est envoyé exactement. Le fait que CodeSurf supporte un outillage d’agents côté local (MCP) ouvre la porte à des workflows où les appels sont contrôlés par un serveur local, avec des permissions explicites et des actions outillées (lecture/écriture fichiers, commandes, recherche) plus traçables.

Enfin, le stockage local sous un dossier dédié rend le modèle mental clair : le workspace est un artefact. On peut en créer un par projet, ou un par sujet, et les retrouver comme des environnements de travail préconfigurés. Concrètement, c’est un outil qui vise à rendre le contexte visible et manipulable, plutôt que de le laisser dispersé entre dix fenêtres.