test(v1.1.18): upgrade or install on Linux and report behavior

[Fmarzochi]

Mission

Upgrade to or install EGC v1.1.18 (latest) on Linux and report whether it works correctly.

v1.1.18 made the installers honest end to end: Claude Code MCP servers are now registered through the real CLI instead of a config file nothing reads, the project .mcp.json is merged from the directory you actually ran the installer in, Continue.dev and Zed are finally registered by the shell installers, and a headless run says so clearly instead of pretending it started a dashboard. This mission checks that all of that holds on a real Linux machine, on your distro, with your shell.

Steps

npm install -g @egchq/egc
egc install
egc doctor
cd <a-real-project>
egc init

Note: after a bare egc install, egc doctor reporting "No EGC install-state files found" and a missing state.db is expected: the core runtime is installed, nothing more. It is egc init (run inside a project) that creates the state store, bootstraps your AI tools and starts the dashboard. That is the moment the two behavior questions below refer to.

If you already have an older version, run the same commands and note anything odd during the transition. If egc doctor reports anything unexpected after egc init, paste it: that is exactly the kind of thing this mission exists to catch.

What to report (as a comment here)

• Distro and version, Node.js version, shell, and how Node is installed (distro package, nvm, mise, asdf, ...)
• Output of egc --version and the final egc doctor summary
• Whether the dashboard opened after egc init
• Whether your AI tools picked up EGC afterwards
• Anything that looked wrong, however small

Why this matters

"Linux" is not one platform. Node installed through nvm, mise, asdf, snap or a distro package puts binaries and global packages in different places, and an installer that assumes one layout silently misbehaves on the others. The maintainer can only test the layout on his own machine; your distro is the one nobody has checked.

No code required. A careful report is the whole contribution, and it gets you credited in the release notes and the Hall of Fame.

[rathaur-ankit]

Environment

• Distro and version: Ubuntu 26.04 LTS
• Node.js version: v22.22.1 (npm 9.2.0)
• Shell: zsh
• How Node is installed: Global/Distro package (installation required sudo npm install -g)

Outputs

egc --version

1.1.18

egc doctor summary

No EGC install-state files found for the current home/project context.
This is expected after a bare `egc install`; the core runtime is installed.
Run `egc install --target <target> --profile full` when you want to install

State store:
  WARNING: state.db not found at /home/ankit/.egc/egc/state.db
  Run: egc init to create the state store

Behavior Questions

• Whether the dashboard opened after install: No dashboard opened.
• Whether your AI tools picked up EGC afterwards: Not tested / N/A (installation required egc init to proceed further).

Anything that looked wrong, however small

1. Deprecation Warning: During the initial global install, npm threw a warning: npm WARN deprecated prebuild-install@7.1.3: No longer maintained.
2. Missing Optional Dependency: egc install reported Optional dependency not found: uv, though it correctly noted that core installation was unaffected.
3. Permissions / Linking Error: During egc install, a linking step failed with the message:
   note: npm link failed (no permission to the global npm prefix?). Run 'npm link scripts/egc.js <command>' from this checkout.
   Context: The initial npm install -g @egchq/egc was executed with sudo, which likely caused the permission mismatch when running the subsequent egc install command without elevated privileges.

More Information

[Fmarzochi]

Hi @rathaur-ankit, welcome back! Great to see the author of the German README translation return for the v1.1.18 testing round. Thank you for another careful, well-structured report: distro-package Node with a root-owned global prefix is exactly the layout this mission existed to catch, and you caught something real.

Here is what each finding means on our side:

1. prebuild-install deprecation warning: known and cosmetic. It is a transitive dependency of better-sqlite3 (our SQLite bindings); nothing in EGC calls it directly and it does not affect the install. It goes away when upstream migrates off it.

2. Optional dependency not found: uv: working as intended. uv is only needed for the Jira and omega-memory MCP servers, and the installer labels it optional thanks to feedback from the previous testing round.

3. The npm link failed note: this one is a real bug, nice catch. When egc install runs after npm install -g @egchq/egc, that link step is redundant: the egc command on your PATH already points at the freshly installed package, which is why egc --version and egc doctor worked fine right after. The step exists for people running from a git checkout, and with a root-owned global prefix it fails and prints a note about a "checkout" you do not have. The installer should detect that it is running from the global npm install and skip the link entirely. The fix is already up in fix(install): skip npm link when the installer runs from the global npm install #1231 and you are credited in it.

4. Doctor output, no dashboard, AI tools not tested: your reading is correct, and this is expected v1.1.18 behavior. The mission steps did not tell you that, which is on us. A bare egc install sets up the core runtime only. The full experience comes from the next step:

   cd <your-project>
   egc init

   That creates the state store (the state.db the doctor warned about), bootstraps the cognitive protocol for your AI tools, re-runs the doctor and starts the dashboard at http://localhost:7890. If you have a few minutes, running egc init inside a real project and telling us whether your AI tools picked EGC up afterwards would complete the mission end to end. I have updated the mission text so the next tester sees this step from the start.

Your environment details (Ubuntu 26.04, distro Node 22 with npm 9, zsh, sudo global prefix) are coverage we simply cannot produce on our own machines. You will be credited in the release notes for this round, as promised.

Two more things:

• We coordinate testing missions and releases on Discord, and you are very welcome there: https://discord.gg/TxppsGb52
• If you would like to turn finding 3 into your first code contribution, I would be happy to walk you through it (fork the repo, small well-scoped fix, I review). No pressure at all: the report alone is already a real contribution.

[rathaur-ankit]

EGC Linux Behavior Report follow up (v1.1.18)

1. Environment Details:

• Distro and version: Ubuntu 26.04 LTS
• Node.js version: v22.22.1 (npm 9.2.0)
• Shell: zsh
• How Node is installed: Global/Distro package (installation required sudo npm install -g)

2. EGC Version and Doctor Output:

• Output of egc --version: v1.1.18
• Final egc doctor summary:

  No EGC install-state files found for the current home/project context.
  

3. Dashboard Behavior:

• Did the dashboard open after egc init? No. The terminal output stated EGC Dashboard starting at http://localhost:7890, but the process exited instantly and dropped me back to the shell prompt. Navigating to http://localhost:7890 in the browser resulted in an ERR_CONNECTION_REFUSED error.

4. AI Tools Detection:

• Did your AI tools pick up EGC afterwards? During egc init, it did print that it detected Antigravity CLI and Gemini CLI, though the server itself failed to stay up.

5. Additional Observations (What looked wrong):

• Silent crash: The server failed to start or crashed silently in the background without throwing an explicit error message in the terminal.
• Missing state file: The GitHub issue notes that egc init should create the state store, but running egc doctor immediately after egc init still resulted in a "No EGC install-state files found" warning.

6.More Information

[Fmarzochi]

Thank you for running the follow-up so quickly, @rathaur-ankit! This second report is just as useful as the first one. Here is what your output tells us:

Good news first: your state store is fine. The line [bootstrap-state-db] OK /home/ankit/.egc/egc/state.db (6 migrations) in your screenshot means egc init created the state store correctly, and the cognitive protocol reached your Gemini CLI. The doctor line "No EGC install-state files found" refers to something else: managed tool profiles created by egc install --target <tool> --profile full, which you have not run (and did not need to for this mission). You are the second tester in a row to read that doctor wording as a missing-state problem, so the confusion is on our side, not yours. Noted for a wording improvement.

The dashboard result is a real finding. The launcher announces the URL and then starts the server as a detached background process with its output discarded, so when the server dies during startup you get exactly what you saw: a promise, an instant exit, and a refused connection, with no error anywhere. That silence is our problem regardless of what killed the server.

If you have two more minutes, this single command would tell us exactly what is failing on your machine (it runs the same startup in the foreground, where errors are visible):

node /usr/local/lib/node_modules/@egchq/egc/scripts/dashboard.js start

My working hypothesis: on first launch the dashboard installs its own dependencies inside the package directory, which is root-owned on your setup. That would be the same class of problem as the npm link note you caught earlier, which is already fixed on main thanks to you (#1231). If that command shows a permission error, the hypothesis is confirmed.

One more piece of context: the dashboard component's future is being actively decided right now (reworked or replaced), and field reports like yours are exactly the evidence that decision needs. You will be credited for this one too.

[rathaur-ankit]

Your hypothesis was exactly right! Running the startup script in the foreground revealed a permission error (EACCES) because it is trying to create a node_modules directory inside /usr/local/lib, which is root-owned on this setup.

[Fmarzochi]

Confirmed, and that screenshot closes the case. Thank you, @rathaur-ankit!

Summary of what you found today, all now on the record:

1. The misleading npm link note: fixed on main in fix(install): skip npm link when the installer runs from the global npm install #1231, credited to you.
2. The dashboard dying silently on first launch when the global prefix is root-owned: root cause confirmed by your foreground run (EACCES on the on-demand dependency install inside the package directory), now formally tracked in bug(dashboard): first launch dies silently when the global npm prefix is root-owned (EACCES on on-demand npm install) #1233 with full credit to you. The fix direction is tied to an active architecture decision on the dashboard component, so today it is documented rather than patched.
3. The doctor wording that reads like a missing-state problem right after a successful egc init: noted for improvement.

That is a genuinely productive testing day: one fix merged, one bug tracked with a confirmed root cause, one UX improvement queued. The release notes credit for this round is yours. If you ever feel like turning any of this into code, the door (and the fork) is open, and I will walk you through it. And Discord awaits whenever you want to hang out: https://discord.gg/TxppsGb52