Settings
The JetBrains plugin surfaces the whole daemon under Settings / Preferences → Tools → insrc — a native settings tree, not a config file you hand-edit. The parent page is a live editor for the entire daemon configuration; three child pages give you an operational cockpit for the daemon, the tracked-workflow chain, and diagnostics. Every read runs off the UI thread against the local daemon socket; every write goes through the daemon's own config.write contract.
~/.insrc/config.json directly — it reads the catalog over the config.catalog IPC and writes single leaves over config.write, so the daemon stays the single source of truth and reconciles/validates every change on its side.Where to find it
Open your IDE's settings (⌘, on macOS, Ctrl+Alt+S on Windows/Linux) and expand Tools → insrc. Under it sit three child pages:
| Page | What it is |
|---|---|
| insrc (parent) | The configuration editor — every daemon setting, grouped and editable live. |
| Daemon | Health readout + lifecycle controls (start / stop / restart / update / backup / compact). |
| Workflows | Read-only status of the tracked define → design → plan → build chain per epic. |
| Debug | Diagnostics: daemon status, stray-process cleanup, MCP clients & attached sessions, and live log tails. |
The configuration editor (parent page)
The parent insrc page renders the daemon's whole configuration catalog as one scrolling page of collapsible category sections. Each setting shows its current value, its default, and an inline description; edits apply through the daemon and are reconciled + validated there. The catalog is grouped so the surface stays legible:
| Group | Controls | Example keys |
|---|---|---|
| General | Daemon-wide basics. | logLevel, ollama.host |
| Workflow & review | How features are routed, gated and reviewed. | permissions.mode, routing.mode, classifier.confirmIntent, codeReview.enforce, codeReview.freshnessTimeoutMs |
| Analysis & memory | Analyzer routing and implicit memory capture. | analyzer.useLocal, memory.implicitCapture.enabled |
| Models — tiers | The per-tier backend + model, and the accuracy floor. | models.tiers.{core,mid,cheap}.{runner,model}, models.coreFloor |
| Models — shaper | The local shaper's loop + output limits. | models.shaper.maxToolTurns, …structuredOutputRetries, …ollamaNumCtx, …ollamaNumPredict |
| Models — plan depth | Max plan-tree depth per scope size. | models.maxPlanDepth.{XS,S,M,L,XL} |
| Local & embeddings | The local Ollama provider + the indexer's embedder. | models.local.host, …embeddingModel, …embeddingDim, …coreModel |
core / mid / cheap), and models.coreFloor guarantees the critical roles — design, review, build, validate — never run below that floor, no matter how you tune the cheaper tiers for classification, probes and summaries. Set a tier's runner to ollama to keep it fully local, or cli-claude / cli-codex to route it through your installed CLI's OAuth session. See the architecture page for the model-tiering design.Per-role overrides
Below the catalog, a collapsible per-role section lets you override the tier/runner/model for an individual workflow role (for example, pin review to a stronger model than the rest) without changing the global tiers. Each override is a leaf write, so clearing it falls back to the tier default.
Per-repo overrides
A collapsible per-repo section does the same at repository granularity — coreFloor, per-task tiers, and per-tier {runner, model} scoped to one registered repo (the daemon's models.byRepo map). Use it to run one heavy repo entirely on cloud tiers while keeping the rest local. The picker lists the repos the daemon has registered.
Daemon page
A live health readout of the backing daemon over the daemon.status IPC — running state, uptime, index-queue depth, pending embeddings, model-pull progress, on-disk index size and registered-repo count — plus the six lifecycle actions, each run off the UI thread with streamed progress:
| Action | What it does |
|---|---|
| Start / Restart / Update | Runs the daemon's own daemon-ctl.sh lifecycle script (the same one the CLI uses) — start can't go over the daemon's own socket, so these go through the script. |
| Stop | A graceful shutdown over the socket; an already-stopped daemon is treated as success. |
| Backup | Backs up the daemon's stores to a folder you pick (prompted first; cancel does nothing). |
| Compact | Compacts the LMDB store; the daemon refuses (with the reason surfaced) while the indexer is busy. |
Workflows page
A read-only projection of the tracked-workflow chain for the open project — it scans .insrc/artifacts and shows, per epic: whether define and the HLD exist and are approved, each story's design / approval / staleness state, the amendment tally, and the suggested next action. It mirrors the CLI's chain view exactly, including the staleness hashing, so the IDE and CLI never disagree. It surfaces status only — there is no approve / reject / amend here (those stay explicit, in-chat actions).
Debug page
The diagnostics cockpit, assembled as an ordered set of read-only sections. The only control anywhere on the page that changes system state is the confirm-gated orphan-process kill — everything else observes:
- Daemon status. The same status snapshot as the Daemon page, plus locally-derived socket path, PID and installed-daemon version.
- Orphan processes. Enumerates stray daemon-entry processes (via
java.lang.ProcessHandle), excluding the managed one, and offers a confirm-gated kill that acts only on your explicit selection and degrades to “unsupported” off a capable platform. This is the single mutating action in the whole settings surface. - MCP clients. Per-host registration status — which detected AI hosts (AI Assistant, Junie) carry the insrc MCP registration — combined with the sessions currently attached to the daemon socket (id, label, pid, connect time), degrading to a clear line when the daemon is unreachable.
- Logs. Opens the daemon or agent log as a live, filterable, read-only editor tab — a normal IDE editor, not an inline panel — streaming new lines as they are written, with a level / module / text filter applied to the view. Nothing you do deletes, rotates or clears the underlying log.
Design notes
- Read-only by default. Every surface here observes the daemon's own state; the only mutations are the config edits (through
config.write), the Daemon-page lifecycle actions, and the Debug orphan kill — each explicit and, where it matters, confirm-gated. - Off the UI thread. Every socket read, file scan, process scan and lifecycle action runs on a pooled thread with the render marshalled back safely — the IDE never blocks on the daemon.
- No cloud path, no stored secrets. Like the rest of the plugin, these pages reach only the local socket, local files and local processes; all model access still routes through your assistant's own CLI / OAuth sessions.
- Nested under one unchanged node. The three child pages hang off the existing
Tools → insrcnode as declarative child pages — the parent configuration editor is untouched by them.