GSoC 2026 – Interest: Multi-IDE Integration Enhancement (#4)

[Devnil434]

GSoC 2026 – Interest: Multi-IDE Integration Enhancement (#4)

Hi @skeshive Ma'am, I'm Nilanjan, an open-source contributor interested in AI systems, developer tools, and CLI-based AI agents.

I have contributed to several open-source projects through programs like GSSoC 2025, Hacktoberfest 2025, Open-Odyssey 2.0, and Open Source Connect, with contributions including SohojNotes (PR #33), HRRoadways (PR #616, PR #431, Issue #596, PR #673), AlgoVisualizer (PR #267, PR #265, PR #260), Privacy Analyzer (PR #16), and Codify (PR #431).

I have also recently started contributing to Gemini CLI directly, with active PRs #22411, #19825, and #21288, #21738 currently in progress.

Before submitting my full proposal, I wanted to open a focused technical discussion and get early feedback from the team.

---

What I've read so far

• The full IDE Companion Spec — including the discovery JSON format, ide/contextUpdate push notification structure, the IdeContext payload shape (open files, cursor pos, selection), and the openDiff tool contract
• packages/vscode-ide-companion/src/ end-to-end as the reference implementation
• packages/core/src/ide/ — how the CLI reads the discovery file, connects to the companion MCP server, and injects context into prompts
• Issues #16111 (hardcoded TERM_PROGRAM=vscode forcing 3rd-party editors to spoof), #15538 (deepening official integrations), and #3899 (original IDE integration feature request)

---

My read on current state

IDE	Status
VS Code	✅ Full companion spec implemented
Zed	⚡ Connected via ACP (subprocess), but openDiff + ide/contextUpdate spec features not yet wired
JetBrains (IntelliJ / PyCharm / WebStorm)	❌ No detection, no plugin — highest user demand
Neovim	❌ ACP path exists but no Lua companion implementing the spec

The most impactful unfinished work is JetBrains and Neovim — both have open community issues with no official implementation. Zed via ACP is great, but the gap between ACP-mode and the full companion spec features is also worth closing.

---

Proposed deliverables (175hr)

1. JetBrains Companion Plugin (Kotlin, IntelliJ Platform SDK)

• MCP HTTP server using Ktor or the official Kotlin MCP SDK
• Writes the discovery JSON file on plugin startup
• Sends ide/contextUpdate notifications on FileEditorManagerListener and caret change events
• Implements openDiff using IntelliJ's DiffManager API
• Covers IntelliJ IDEA, PyCharm, WebStorm, and GoLand via a single plugin (shared Platform SDK)
• Published to the JetBrains Marketplace

2. Neovim Companion Plugin (Lua)

• Lua plugin that spawns a lightweight MCP HTTP bridge (via Node.js subprocess or pure-Lua vim.loop socket)
• Sends ide/contextUpdate on BufEnter and CursorMoved autocmds
• Implements openDiff by opening a native Neovim split diff buffer
• Distributed via lazy.nvim / packer.nvim

3. Generalized IDE detection in packages/core

• Replace the hardcoded TERM_PROGRAM=vscode check with a config-driven lookup table (resolves #16111)
• Detect JetBrains via TERMINAL_EMULATOR=JetBrains-JediTerm, Neovim via NVIM socket env, Zed via its ACP socket
• Extensible so future editors can be added without code changes

4. Integration test harness + docs

• A mock companion server test fixture for packages/core/src/ide/ so future IDE additions have a test target
• Setup guides for JetBrains and Neovim in docs/ide-integration/

---

Architecture overview

---

Questions for the mentor

1. JetBrains MCP library choice — should I use the official Kotlin MCP SDK or Ktor with a hand-rolled JSON-RPC layer? The official SDK is newer and might add plugin weight.

2. Neovim MCP bridge — is a Node.js subprocess acceptable, or should the Neovim plugin be fully self-contained Lua? A pure-Lua HTTP server via vim.loop is feasible but more work.

3. Zed ACP gap — is wiring openDiff + ide/contextUpdate into the ACP path in scope for this project, or is that tracked separately with the Zed team?

4. Discovery file on Windows — the spec uses a temp file path; JetBrains on Windows uses different temp directory conventions. Any preference on cross-platform handling?

---

My relevant background

• TypeScript / Node.js (primary stack), Python, React — comfortable reading and writing packages/core and packages/cli without friction
• Built ChainPilotAI — an MCP-based supply chain intelligence platform — so I'm already familiar with the MCP protocol from both server and client sides
• Built a Multi-Document RAG System with BM25 + vector search + reranking pipeline
• 2nd place, Smart India Hackathon 2024 | Top 105 Global Teams, Google Solution Challenge 2025
• Actively contributing to Gemini CLI with PRs #22350, #19825, #21288

For Kotlin (JetBrains SDK) and Lua (Neovim), I'm in active ramp-up — I've gone through the IntelliJ Platform Plugin SDK quickstart and the Neovim Lua guide this week. I want to be upfront about that rather than oversell it.

---

I'm also planning to submit a focused PR fixing the hardcoded TERM_PROGRAM detection (#16111) as a first scoped contribution before the proposal window opens.

Happy to hear any feedback on scope or priorities — especially whether JetBrains or Neovim should be the primary focus given the 175hr budget.

Thank you!