Unsupervised/claude-nova
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Move to a terminal driven integration to have better interactions

Browse Source
This commit is contained in:
thatguygriff
2026-08-11 17:10:26 -03:00
parent 89d1a06204
commit b05c28cff0
26 changed files with 679 additions and 4058 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/features/ide-bridge.md
+21 -21
View File
@@ -1,31 +1,31 @@
# IDE bridge
**Status: Proposed — not built.** This is a design note, not a description of
**Status: Next — not built.** This is a design note, not a description of
shipped behaviour.
This is now the main roadmap item. With chat in a terminal, the bridge is what
gives that session access to Nova: the selection, the open files, and diffs
rendered for review in the editor instead of as terminal text.
> Provenance: the protocol details below come from
> [coder/claudecode.nvim](https://github.com/coder/claudecode.nvim)'s
> `PROTOCOL.md`, which documents a working reimplementation of the same
> integration the VS Code extension uses. **None of it has been verified against
> the CLI by this project** — unlike the stdio protocol in
> [session transport](session-transport.md), which has. Treat every claim here
> as needing a first-run check.
> the CLI by this project.** Treat every claim here as needing a first-run
> check. (The stdio protocol the extension used previously *was* verified; that
> work is in commit `89d1a06`.)
## What it would add
Today the extension **drives** Claude: it spawns `claude --print` and owns the
session. The IDE bridge inverts that — Nova becomes a **server** that a `claude`
process running in a terminal connects to, so the terminal session can see the
editor:
Nova becomes a **server** that the `claude` process running in your terminal
connects to, so that session can see the editor:
- the current selection and open files as context
- diffs pushed into Nova for review rather than rendered as terminal text
- "open this file at this line" from Claude
The two modes are complementary, not competing. Driving is better for an
in-editor chat surface; the bridge is better if you live in the terminal — and
it gets the rich Claude Code TUI for free, which is the one thing Nova's UI
cannot render well.
The extension already launches the terminal session (see
[launching](launching.md)); the bridge is the return path.
## How discovery works
@@ -61,7 +61,7 @@ Messages are JSON-RPC 2.0 over RFC 6455 WebSocket.
| `getWorkspaceFolders` | ✅ `nova.workspace.path` |
| `checkDocumentDirty` | ✅ `document.isDirty` |
| `saveDocument` | ✅ `editor.save()` |
| `openDiff` | ⚠️ No diff viewer API. Reuse the editable-proposal pattern from [tool approvals](tool-approvals.md): stage the proposed file, open it, and map save → `FILE_SAVED`, close → `DIFF_REJECTED`. The tool blocks until one of those. |
| `openDiff` | ⚠️ No diff viewer API. Reuse the editable-proposal pattern: stage the proposed file, open it, and map save → `FILE_SAVED`, close → `DIFF_REJECTED`. The tool blocks until one of those. Working code for this — including change reconstruction and a unified diff renderer — is in commit `89d1a06` (`Scripts/diff.js`, `Scripts/permissions.js`). |
| `close_tab` | ❌ Nova cannot close tabs programmatically |
| `closeAllDiffTabs` | ❌ same |
| `getDiagnostics` | ❌ An extension can only read its own `IssueCollection`. Claude running the linter itself via Bash is the workaround. |
@@ -78,8 +78,8 @@ sidecar** spawned via `Process`, with the extension and sidecar talking over
stdio — `Process` supports `stdio: "jsonrpc"`, which is a natural fit here since
the payloads are already JSON-RPC.
That means Node 18+ becomes a runtime requirement, which v1 deliberately avoided.
Gate it behind a setting that is off by default.
That means Node 18+ becomes a runtime requirement, which the extension has so
far avoided. Gate it behind a setting that is off by default.
```
Nova extension ──jsonrpc/stdio──> node sidecar ──ws──> claude (terminal)
@@ -94,10 +94,10 @@ to it** — commands can only be placed in the `editor`, `extensions`, `text` an
`command-palette` menus, and there is no terminal object in the API surface.
So the realistic shape is: the extension runs the sidecar and publishes the lock
file; the user opens Nova's terminal themselves and runs `claude`. Discovery is
automatic from there — the CLI finds the lock file without being told. A
`claudenova.copyTerminalCommand` helper could put the right `env` prefix on the
clipboard for shells that do not inherit it.
file; you paste the launch command into Nova's terminal as you already do.
Discovery is automatic from there — the CLI finds the lock file without being
told. If the environment variables do not reach the terminal, `launch.js` can
prefix them onto the copied command.
If Panic ever exposes a terminal API, the only change is automating that last
step.
@@ -108,8 +108,8 @@ step.
accepted?
2. What does it do with tools that answer "unsupported" — degrade, or error the
turn?
3. Can the bridge and the driven session coexist in one window without the CLI
getting confused about which IDE it is attached to?
3. With several terminal sessions open in one project, do they all attach to the
same lock file — and does the editor need to distinguish them?
4. Lock-file lifecycle: who cleans up after a crash? (`pid` is in the file
precisely so stale entries can be detected.)