Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/amicus/issues.md or /mcp/amicus/issues.json, or Pod over MCP.

Reported issues for Amicus

Pod holds 16 of 19 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to Amicus.

Most discussed

Updater: npx cache pins a stale opencode, breaking every MCP session behind a misleading NO_OUTPUT_BACKSTOP

Summary

The MCP launch path (npx -y amicus@latest mcp) and the CLI path (global install) can end up bundling different opencode versions. When they do, every MCP-spawned session dies — but the reported reason blames the model, sending you off debugging model IDs, API keys, and gateways instead of the engine.

Observed on Windows 11, amicus v4.7.0 (identical version on both paths).

Symptom

Every amicus_start via MCP failed identically, regardless of model or gateway:


[Read the thread](https://github.com/BourbonDog/amicus/issues/133) · 2026-08-08 · closed · 2 comments

### Electron: lazy first-GUI-use provisioning via a separate ensureElectron() (do not overload getElectronPath)

## Problem

On a broken-GUI install, `runInteractive` (`src/sidecar/interactive.js:98`) just bails with an error string telling the user to reinstall — the exact reinstall loop the report flags. There's no attempt to provision the binary on first GUI use.

## Fix

Add an `ensureElectron()` (the provisioning variant of `repairElectron`) and call it **only** from the two GUI-launch sites:
- `src/sidecar/setup-window.js:21` (setup wizard launch)
- `src/sidecar/interactive.js:200` (`getElectronPath(

[Read the thread](https://github.com/BourbonDog/amicus/issues/55) · 2026-06-30 · closed · 1 comment

### Unify project-directory handling: one shared canonicalProjectPath() + directory-threading convention (#39/#40/interactive)

## Problem

The interactive `--cwd` bug, #39 (honor MCP roots / `AMICUS_PROJECT_DIR`), and #40 (global session index) are all symptoms of amicus never threading a **single canonical project directory** through (a) `session.create`, (b) per-session API calls, and (c) the Web-UI route / session index. Shipping three independent path normalizers would re-create the very inconsistency these issues describe.

## Fix

- Land ONE shared, well-tested, **pure** `canonicalProjectPath(p)` helper (Windows s

[Read the thread](https://github.com/BourbonDog/amicus/issues/48) · 2026-06-30 · closed · 1 comment

### Scope the OpenCode session to directory on the shared-server MCP path (mcp-server.js)

## Problem

The shared-server MCP path (`src/mcp-server.js:130`) also calls `createSession(client)` with **no directory**, against an OpenCode server shared across projects. This is the same "session not found in project" bug class for headless MCP sessions, and the surface of #40 (global session index): a session created project-unscoped is found by id but not by a `?directory=` query.

## Fix

Thread the same canonical `directory` (from the MCP project resolution — see #39 honor-MCP-roots / `A

[Read the thread](https://github.com/BourbonDog/amicus/issues/47) · 2026-06-30 · closed · 1 comment

### amicus_status: bound elapsed by completedAt/abortedAt/crashedAt instead of wall-clock from now

## Problem

`amicus_status` computes `elapsed` as `Date.now() - createdAt` in both the single-session (`src/mcp-server.js:336-339`) and wave (`:309-313`) branches, ignoring `completedAt`. For a terminal session, `elapsed` keeps growing with wall-clock time after completion — e.g. a 2.1s run shows `0m 22s` after a delayed poll. It reports how long ago the session *started*, not how long it *ran*.

## Fix

Bound the end by `completedAt ?? abortedAt ?? crashedAt ?? Date.now()` and apply to **both**

[Read the thread](https://github.com/BourbonDog/amicus/issues/42) · 2026-06-30 · closed · 1 comment

### Make 'Session not found' errors name the resolved project

## Problem

When a session cannot be found, `amicus_status` (`src/mcp-server.js:262`) and `amicus_read` (`:375`) return a bare `Session <id> not found.` that omits the resolved project path — which is exactly the missing-`project` / wrong-default cause (the project auto-roots to the Claude app dir). The user has no signal that they need to pass the original `project`.

## Fix

Include the resolved `cwd` / project in the not-found message, e.g.:

> Session <id> not found in project <X> — it may h

[Read the thread](https://github.com/BourbonDog/amicus/issues/41) · 2026-06-30 · closed · 1 comment

### Project resolution: honor MCP client roots + add AMICUS_PROJECT_DIR when project is omitted

## Problem

`getProjectDir()` (`src/mcp-server.js:17-23`) falls back to `process.cwd()` when no `project` is passed, with no MCP `roots` support, no env override, and no sanity check. A stdio MCP server spawned by the Claude desktop client inherits the client's install folder as cwd (e.g. `...\AnthropicClaude\app-1.15962.1`), so headless agents are rooted in the **app dir** — they cannot read the user's files, and their session artifacts land under the app dir's `.claude/`. The resolved value fl

[Read the thread](https://github.com/BourbonDog/amicus/issues/39) · 2026-06-30 · closed · 1 comment

### Council/headless: failed runs recorded as status:complete with empty summary (shared-server MCP path swallows the error)

## Problem

On the shared-server MCP path, a headless session/council whose model calls all failed (e.g. OpenRouter HTTP 402 "Insufficient credits") is recorded as `status: complete` with a **0-byte summary** and **no error**. `amicus_status` → `complete`; `amicus_read` → `**Model:** <id>` with an empty body. A council where every paid model was rejected reports success.

## Root cause (confirmed v1.5.1)

Terminal-state classification is forked and only the CLI path is correct:

- **CLI-spawn pa

[Read the thread](https://github.com/BourbonDog/amicus/issues/36) · 2026-06-30 · closed · 1 comment

## Most recent

### Council Workspace auto-open is MCP-only: "amicus council run" (CLI) never opens the window

## Summary

The v4.5 Workspace auto-open decision is wired into the **MCP** council handler only. Launching the identical council through the **CLI** (`amicus council run`) silently never opens the Workspace, with no notice that a GUI was available and skipped.

Same run, same machine, same `client: code-local` — two different outcomes depending purely on transport.

## Evidence

**MCP path has it** — `src/mcp-council-run.js:236-246`:

```js
// ★ v4.5 auto-open (spec §6): decide via the pure hel

[Read the thread](https://github.com/BourbonDog/amicus/issues/81) · 2026-08-01 · closed · 0 comments

### doctor's Electron check validates the wrong install when MCP server runs from npx-cache

## Summary
`amicus doctor` reports Electron as installed, but `amicus_council_run` with `ui: true`
consistently returns `workspaceOpened: false, workspaceOpenReason: "electron-absent"` —
across three attempts, including after a full session/MCP-server restart.

## Root cause
Two independent amicus installs exist on the same machine:
1. **Global npm install** (`%APPDATA%\npm\node_modules\amicus`) — what a normal shell
   resolves `amicus` to, and what `doctor` checks. Electron was fully installed

[Read the thread](https://github.com/BourbonDog/amicus/issues/76) · 2026-07-30 · closed · 0 comments

### Make the github: install path run identically on Windows (so README's 'runs identically' claim holds)

## Goal

Make `npm install -g github:BourbonDog/amicus` succeed on Windows and register MCP + skills **exactly like the registry install**, so the README claim that the github: install "runs identically — same MCP registration, same two skills" (`README.md:113`) becomes true — rather than softening it with a Windows caveat.

## Background / corrected root cause

A Windows v1.5.1 install report saw `npm install -g github:BourbonDog/amicus` roll back the whole package: the package's own `postinsta

[Read the thread](https://github.com/BourbonDog/amicus/issues/35) · 2026-06-30 · closed · 1 comment

### Surface running amicus version (+ on-disk mismatch warning) in MCP tool responses

## Problem

No MCP tool response surfaces the running amicus version — the only version reference is `McpServer` handshake metadata (`src/mcp-server.js:665`) that the agent never sees in a tool result. After `npm i -g amicus`, the long-lived MCP stdio child keeps the old `require()`'d modules in memory until the client restarts, and this staleness is undetectable from inside an agent session. (Compounded by `amicus_setup` reporting success unconditionally — a stale/broken server is indistinguish

[Read the thread](https://github.com/BourbonDog/amicus/issues/33) · 2026-06-30 · closed · 1 comment

### Build amicus doctor into a self-heal/diagnose hub and point failures at it

## Problem

Several install/runtime failure modes are silent or stale and have no single recovery path:
- missing electron GUI binary (silent exit-0),
- github: install rollback (corrupt git-prep cache),
- transient `opencode-ai` postinstall rollback,
- stale MCP server keeping old code after a reinstall.

`amicus doctor` already reports the version (`src/cli-handlers-doctor.js:164`) and warns on missing electron (`src/cli-handlers-doctor.js:111-115`) — the plumbing exists.

## Fix

Extend `src/

[Read the thread](https://github.com/BourbonDog/amicus/issues/32) · 2026-06-30 · closed · 1 comment

### Make package postinstall non-fatal so internal failures don't roll back the whole global install

## Problem

A non-zero exit from `node scripts/postinstall.js` makes npm roll back and uninstall amicus **entirely**. But the postinstall only does optional convenience setup (skill copy + MCP registration) — it should never be load-bearing for the install to succeed. Today any internal throw, or a `MODULE_NOT_FOUND` when the script is missing from a github: install tree (see the github: rollback issue), nukes the whole global install.

The internal operations are already wrapped in try/catch-wa

[Read the thread](https://github.com/BourbonDog/amicus/issues/29) · 2026-06-30 · closed · 1 comment

### amicus_setup MCP tool reports success even when Electron is missing

## Problem

`amicus_setup` (`src/mcp-server.js:638-643`) returns the hardcoded string `Setup wizard launched. The Electron window should appear on your desktop.` regardless of outcome. It calls `spawnSidecarProcess(['setup'])` (`src/mcp-server.js:55-77`) fire-and-forget — stdio ignored, `child.unref()`, no `error`/`exit` listener. The `try/catch` only catches a *synchronous* spawn throw. When Electron is missing (or the child starts and then exits immediately), the user is told setup launched wh

[Read the thread](https://github.com/BourbonDog/amicus/issues/28) · 2026-06-30 · closed · 1 comment

### Remove the legacy sidecar* compatibility shims (next major)

**Umbrella issue — tracked in detail in [`docs/SHIMS.md`](../blob/main/docs/SHIMS.md).**

Amicus v1.0.0 ships every legacy `sidecar*` form as a deprecated shim so upstream `claude-sidecar` users migrate seamlessly: CLI bins (`sidecar`, `claude-sidecar`), env-var prefix (`SIDECAR_*`), config dir (`~/.config/sidecar`), session dir (`.claude/sidecar_sessions`), config token (`[SIDECAR_CONFIG_UPDATE]` / `sidecar-config-hash`), MCP tool aliases (`sidecar_*`), public API exports (`*Sidecar`), and MCP 

[Read the thread](https://github.com/BourbonDog/amicus/issues/19) · 2026-06-11 · closed · 1 comment

The remaining reports are on [the project's issue tracker](https://github.com/BourbonDog/amicus/issues).