Joule for the editor
An agentic coding session in a side panel, driven by the joule you already
run in a terminal. The agent reads and edits the files in your workspace, runs
commands and makes commits on your own machine - the panel is a front end
to a local daemon, not a hosted service and not a second agent.
A terminal and this panel can drive the same session at the same time. Change
the model or the approval mode in either one and the other moves with it,
because both are talking to the same daemon over the same protocol.
Before you install: this needs the joule CLI
The extension does not carry an agent. It starts and attaches to a joule
daemon, so the binary has to be on the machine the workspace is on:
curl -fsSL https://raw.githubusercontent.com/joule-sh/code/main/install.sh | sh
That installs joule for x86_64 Linux, Apple Silicon macOS and Intel macOS.
The extension needs joule 0.13.0 or newer. If joule is not on PATH,
point joule.path at it.
Credentials stay with the CLI. The panel never asks for an API key, never
reads one, and never forwards one.
There is no Windows build yet
joule does not build for Windows
(#173), so on a Windows machine
this extension installs, loads, and then tells you there is nothing for it to
drive. Nothing about the panel will work there. That is a limitation of the
CLI, not of the extension, and it is being worked on.
WSL works today, and is the way to use this on Windows. Open the folder
through WSL (or through Remote-SSH, or in a dev container): the extension
declares itself a workspace extension, so it runs on the remote side, next to
the Linux joule and next to your files. Install joule inside the WSL
distribution with the one-liner above and the panel behaves exactly as it does
on Linux.
What the panel does
It opens on a first-run screen when nothing is configured yet: one
sentence on what joule is, and the three ways it can reach a model - a joule
account, your own provider key, or a self-hosted joule server - each as its
own button. A missing joule, a joule too old to drive, and a configuration
that cannot start a session all land here with a sentence about what to do,
rather than a red error somewhere in the corner.
An API key is never typed into the panel. The provider-key route opens
~/.config/joule-code/config.json in the editor and says so. The extension
reads that file only to answer "is there a key here", never its value, and
writes nothing to it but a server address you asked it to remember.
Approvals are cards, not prompts in a scrollback. When the agent wants to
run a command or write a file that the current mode does not allow on its
own, the panel shows what it wants to do and where it will run, and waits.
The composer carries the session's controls. A chip row names the file
open beside the panel, which is what will be quoted at the top of your
message and can be dismissed with a click. Below the input, the approval mode
and the model sit as chips, with a line saying where tools will run and what
this mode lets through without asking.
It attaches, resumes and reconnects. Close the window and the daemon keeps
working; open it again and the panel picks the session back up.
Getting started
- Install
joule (above) and run it once in a terminal to sign in or point
it at a provider.
- Open a folder in your editor. The session opens in a tab beside your code,
without taking focus from the file you opened.
- Press Attach.
Close that tab and the joule icon in the activity bar, on the left, is still
the way back to the session, as is Joule: Open the session in an editor
tab and the button in the view's own title bar. Set
joule.openInEditorTab to false if you would rather the editor area stayed
yours and the session lived in the activity bar.
Attaching is deliberately a button rather than something that happens on
open: a workspace's daemon may already be driven from a terminal, and joining
it is a decision you make. Set joule.attachOnStartup if you would rather it
happen every time.
Settings
| setting |
default |
what it does |
joule.path |
joule |
the binary the daemon is started and stopped through |
joule.openInEditorTab |
true |
open the session in an editor tab beside your code when the window opens |
joule.attachOnStartup |
false |
attach as soon as the window opens, instead of waiting for the button |
joule.resumeOnStart |
false |
when this window starts the daemon, resume the folder's previous session |
joule.path must be the same install a terminal would use: the daemon is
started and stopped through it.
Commands
| command |
what it does |
Joule: Open the session in an editor tab |
open the tab beside your code, or reveal the one already open |
Joule: Attach to this workspace's session |
start or join the daemon for this folder |
Joule: Detach from the session |
leave the session running and stop rendering it |
Joule: Cancel the current turn |
stop the agent mid-turn |
Joule: Stop this workspace's daemon |
shut the daemon down |
Versions, and what happens when they disagree
The extension and the CLI are cut from the same tag, so a 0.18.0 extension
and a 0.18.0 binary are the pair that was tested together. Attaching runs
joule --version first and refuses to go further when the binary is missing,
is not a joule, or is older than 0.13.0 - the release that first shipped the
daemon and attach socket this panel talks to. A mismatch is one sentence in
the panel rather than a session that dies on the first frame it does not
recognise. A binary built from a checkout reports dev and is taken at its
word.
Installing without the marketplace
Every release also attaches joule-editor-<version>.vsix to
its GitHub release, cut from the
same tag as the binaries:
code --install-extension joule-editor-<version>.vsix
or the Extensions view, through Install from VSIX.
Source, issues, and how it works
The extension is plain JavaScript with no dependencies and no build step, in
editor/ of the
joule-sh/code repository, MIT licensed.
