v1.0.4 — 🛠 A blank window that finally says what's wrong

🛠 A blank window that finally says what's wrong

From a real deployment. A machine built for a customer to run local LLMs came up
with a chat window showing nothing at all — no text, no error, no hint.

Two separate things were wrong, and neither said a word. The engineer who set it
up had installed on dozens of machines without hitting either, and ended up going
through the firewall and the proxy by hand while the customer sat in front of an
empty window.

---

① The installer could finish "successfully" with no Claude Code CLI

PowerShell's default execution policy is Restricted, and in PowerShell
npm resolves to npm.ps1 — a script. So this, inside the installer:

npm install -g @anthropic-ai/claude-code

…was refused outright:

npm : File C:\Program Files\nodejs\npm.ps1 cannot be loaded because
running scripts is disabled on this system.

while npm.cmd --version on the same machine prints 11.9.0 quite happily.

And the installer printed + installed anyway, because that message was
never guarded by a check. Every agent in the office is a claude session, so
this is the entire product failing to install and being reported as a success —
which is why it presented later as a mystery instead of an error.

Now it calls npm.cmd (which no policy can block), lifts the policy for its
own process only — nothing written to the registry, the machine's posture
untouched — and verifies claude is actually on PATH before claiming
anything, printing the real fix if it isn't.

It also asks about the persistent setting, since your own terminal still needs
it for claude and npm afterwards. It explains both ways out and offers to set
RemoteSigned for your user only. It never lowers a machine's script policy
silently — on someone else's customer's machine that is not the installer's call
to make. BAGIDEA_SET_EXECUTION_POLICY=1 for unattended runs.

② An unreachable daemon showed an empty rectangle

The whole UI is served from 127.0.0.1:8787. The shell pointed a webview at it
with no readiness check and no failure path — so when something on the machine
stood between the two, the window painted nothing, forever.

It now waits up to 25 seconds for a slow daemon — a cold boot must never be
reported as a blocked machine — and otherwise shows an embedded page naming
the three real causes (a proxy that doesn't exempt local addresses, a firewall
or antivirus blocking loopback, a daemon that didn't start) and pointing at
bagidea doctor. It retries on its own with a backoff, so a daemon that was
merely slow heals with nobody touching it.

---

🩺 bagidea doctor

The diagnostic that support call needed:

bagidea doctor

• Does anything answer on 127.0.0.1:8787 — and is it refused or hung?
  Those mean different things (nothing listening vs. something swallowing
  loopback traffic) and sending the reader down the wrong one costs an afternoon.
• Is a system proxy or PAC script routing local addresses somewhere else?
• Is HTTP_PROXY set without NO_PROXY covering loopback?
• Will your execution policy refuse claude and npm?
• Is the Claude Code CLI installed at all?

Every finding prints its fix beside it. It runs without the daemon — that is
the case it exists for.

Tests

daemon/tests/unreachable-office.test.js — nine tests across both faults: no
bare npm in the installer, the policy lifted at process scope only, the success
message guarded by a real check, the daemon given time before being declared
unreachable, the offline page naming the causes without fetching anything it
cannot reach, and doctor's bypass-list parsing (<local>, 127.0.0.1,
localhost — but not a list that only covers the corporate network, which is
exactly the configuration that breaks this).

Run against the pre-fix code, six of the nine fail. A test that cannot fail
is not a guard.

---

Full detail: CHANGELOG.md