Everything-Claude-Code on Windows with Codex + Cursor + Antigravity: unclear global vs project setup, hooks/MCP not appearing

[ronfried1]

Everything-Claude-Code on Windows with Codex + Cursor + Antigravity: unclear global vs project setup, hooks/MCP not appearing

Environment

• OS: Windows 11

• Main ECC repo location:

  • C:\Users\user\everything-claude-code

• Tools I use:

  • Codex app / Codex CLI
  • Cursor
  • Antigravity

• Languages:

  • TypeScript
  • Go
  • Python

---

What I want

I want to use Everything-Claude-Code as a single shared installation for all of my tools:

• Codex
• Cursor
• Antigravity

I want one source of truth and no duplication.

For example, I do NOT want:

• one copy of skills in ECC
• another copy in Codex personal/global config
• another copy in Cursor project config

I want to understand the officially recommended setup for Windows when using all of these together.

---

What I already did

I cloned the repo:

git clone https://github.com/affaan-m/everything-claude-code.git
cd everything-claude-code
npm install

Then I installed Cursor support for my languages:

.\install.ps1 --target cursor typescript go python

I also attempted Codex setup and tried the sync script.

At one point I ran:

bash scripts/sync-ecc-to-codex.sh

So I am not sure whether my Codex setup is fully correct or not

---

Current folder state

My ECC folder currently contains:

C:\Users\user\everything-claude-code\
  AGENTS.md
  .agents\
  .codex\
  .cursor\
  ...

More specifically:

.agents\
  plugins\
  skills\

.codex\
  AGENTS.md
  config.toml
  agents\

.cursor\
  .agents\
  agents\
  commands\
  hooks\
  mcp-configs\
  rules\
  scripts\
  skills\
  AGENTS.md
  hooks.json
  ecc-install-state.json

However, I do NOT see:

.cursor\mcp.json

which the docs seem to mention.

---

What currently works

Codex

Codex seems to work globally.

Even when I open a different project (not the ECC repo itself), I can still see and use the ECC skills.

So it looks like Codex is somehow reading the ECC setup globally.

Cursor

Cursor behaves differently.

If I open:

C:\Users\user\everything-claude-code

then inside Cursor I can see:

• rules (only the same "CLAUDE" and "AGENTS" in different translations)
• skills
• agents
• commands

But when I open a completely different project in Cursor, I do NOT see any of those ECC features anymore.

This makes it seem like Cursor only reads the .cursor folder and AGENTS.md from the currently opened workspace.

---

My confusion about the docs

The Cursor manual installation docs say:

cp -r .cursor/rules/* ~/.cursor/rules/
cp -r .cursor/hooks/* ~/.cursor/hooks/

and also:

AGENTS.md is auto-detected from repo root

So I am confused:

1. Are rules/hooks supposed to be global via ~/.cursor?
2. Are skills/agents/commands supposed to be per-project only?
3. Is there an official supported way to make the full ECC Cursor setup global across all projects?
4. Or is the intended way to symlink / junction .cursor into every project?

---

MCP problem

I cannot see any MCP configuration in Cursor.

Even when I open the ECC repo itself, I do not see any MCP servers configured.

The repo generated:

.cursor\mcp-configs\

but not:

.cursor\mcp.json

Questions:

1. Is .cursor/mcp.json supposed to be generated automatically?
2. If not, what is the correct way to turn the contents of mcp-configs into an actual Cursor MCP configuration?
3. Is there a missing install flag or additional command?
4. Is MCP intentionally not enabled by default?

---

Hooks problem

I can see hooks in Cursor when opening the ECC repo, but I get an error.

The error is something like:

needs to be a number

I suspect it is related to hooks.json or one of the generated hook configs.

My .cursor folder currently contains:

.cursor\hooks.json
.cursor\hooks\...

Questions:

1. Is there a known issue with the generated Cursor hooks on Windows?
2. Are there any fields in hooks.json that are incorrectly written as strings instead of numbers?
3. Has anyone else seen this error after running:

.\install.ps1 --target cursor typescript go python

4. Is there a recommended fix?

---

Antigravity

I have not yet fully installed Antigravity support.

I understand from the docs that I probably need:

.\install.ps1 --target antigravity typescript go python
robocopy .\.agents\skills .\.agent\skills /E

Can someone confirm whether that is the officially recommended setup on Windows?

---

Main questions

1. What is the officially recommended Windows setup for using ECC with BOTH Codex and Cursor together?
2. Why does Codex appear to work globally, while Cursor only works inside the ECC repo?
3. Is Cursor expected to require .cursor / AGENTS.md in every project?
4. If yes, is the recommended approach to use symlinks/junctions into each project?
5. Why is .cursor/mcp.json missing?
6. Why do hooks throw "needs to be a number"?
7. Are there any Windows-specific instructions that are missing from the docs?

Thanks!

[pauldev-hub]

Hi @ronfried1 ,

Root cause first — ECC and Cursor have fundamentally different scopes, and mcp.json is NOT auto-generated by ECC's install script.

Q1 & Q2 — Global vs project scope: how it actually works

Cursor has two tiers:

Global (~/.cursor/) → rules, hooks apply across ALL projects

Project-local (.cursor/ in repo root) → agents, skills, commands, MCP

ECC's install script copies into .cursor/ inside the ECC repo itself — not into ~/.cursor/. That's why Codex appears global (it reads from ~/.codex/) but Cursor only works inside the ECC repo.

Fix for global rules/hooks on Windows:

cp -r .cursor\rules* $HOME.cursor\rules
cp -r .cursor\hooks* $HOME.cursor\hooks\

Q3 & Q4 — Is Cursor expected to require .cursor in every project?

Yes — skills, agents, commands are intentionally per-project in Cursor's design. The officially recommended approach for Windows is directory junctions:

Run in each project root

cmd /c mklink /J .cursor C:\Users\user\everything-claude-code.cursor

This makes every project share one .cursor source of truth with zero duplication.

Q5 — Why is .cursor/mcp.json missing?

ECC generates .cursor\mcp-configs\ (its own format) but does NOT auto-generate .cursor\mcp.json which is what Cursor actually reads. You must create it manually from the mcp-configs content.
Cursor reads MCP config from ~/.cursor/mcp.json for global scope. (FastMCP)

Create it manually:

Global MCP for Cursor (Windows)

New-Item -Path "$HOME.cursor\mcp.json" -Force

Then populate it with the servers from .cursor\mcp-configs\mcp-servers.json in this format:

{
"mcpServers": {
"server-name": {
"command": "cmd",
"args": ["/c", "npx", "-y", "@package/name"]
}
}
}

Windows critical note: On native Windows (not WSL), local MCP servers that use npx require the cmd /c wrapper to ensure proper execution. (Claude)

Q6 — Hooks "needs to be a number" error
This is a Windows-specific type coercion bug. Open .cursor\hooks.json and check for fields like timeout, debounce, or interval — they're likely written as strings:

// Wrong
"timeout": "3000"

// Correct
"timeout": 3000

Fix all such fields to be raw numbers, not quoted strings. This is a known issue with ECC's PowerShell-generated hook configs on Windows.

Q7 — Recommended single Windows setup (no duplication)

Use the ecc2cursor tool — it was built exactly for this:

npx ecc2cursor sync

Syncs skills, agents, rules, MCP to ~/.cursor/ globally

It translates ECC configs to Cursor-compatible formats and installs to ~/.cursor/ with a single command, supporting MCP servers, rules, skills, and agents. (GitHub)

Complete Windows setup order:

git clone + npm install ECC
npx ecc2cursor sync → populates ~/.cursor/ globally
Manually create ~/.cursor/mcp.json from mcp-configs/ with cmd /c npx wrappers
Fix hooks.json number types
For per-project: use junctions pointing to ECC .cursor/

👍 If this helped you, please mark it as the answer — it helps others in the community who run into the same issue find the solution faster!

[affaan-m]

Official clarification from the repo side:

1. The old ecc@ecc install string is stale and incorrect. The canonical marketplace/plugin identifier is everything-claude-code@everything-claude-code.

2. The move to the full identifier was not cosmetic. It is part of aligning the install/discovery surface with the Anthropic marketplace/plugin model so the listing, docs, and install path all use one stable canonical name instead of a repo-local shorthand.

3. On Cursor specifically, there is an important scope distinction:

• global/user-level Cursor config is under ~/.cursor
• project-level Cursor config is the repo-local .cursor/ directory

Codex feels "global" because ECC installs there through the user-level Codex surface. Cursor does not automatically project that same global model onto every workspace.

4. mcp-configs/ is a catalog/config source, not the same thing as an auto-enabled runtime mcp.json. That separation is intentional so MCP activation is explicit instead of silently wiring servers into every install.

5. The current Windows install/name/GateGuard regression set is being fixed in #1439:
   fix: unblock urgent install and gateguard regressions #1439

That PR consolidates the urgent fixes for:

• stale plugin name/docs references
• marketplace install detection
• Windows GateGuard state handling
• Cursor install precedence issues
• .claude/settings.json being blocked by GateGuard

So if you hit the broken name/install behavior on Windows, use #1439 as the current fix path rather than the older fragmented branches.

[affaan-m]

Status update from the repo side:

The urgent Windows/setup breakages are being consolidated in #1439 rather than split across more partial branches.

That branch now covers:

• Windows-safe GateGuard state writes
• stable per-session GateGuard keys
• allowing .claude/settings.json edits so the hook can be disabled/recovered safely
• allowing read-only git introspection like git status
• marketplace-installed plugin discovery under .claude/plugins/marketplaces
• Cursor install precedence preferring native .cursor/rules
• user-facing docs/tests enforcing the canonical install path

Also important: mcp-configs/ is catalog/config source, not the same thing as runtime mcp.json. ECC keeps that activation explicit on purpose instead of silently wiring MCP servers into every environment.

And on naming: the full everything-claude-code@everything-claude-code identifier is not vanity churn. It is the canonical marketplace/plugin identifier, and aligning on that is what keeps listing, install, and support surfaces consistent across Anthropic marketplace installs.

If you were blocked by the older ecc@ecc string or by Windows GateGuard behavior, watch #1439 rather than the superseded partial PRs.

[affaan-m]

Current fix path for the Windows/Cursor/Codex/Antigravity confusion:

• #1439 is merged on main and fixes the urgent install/name/GateGuard breakage.
• #1445 is the follow-up for marketplace-installed hook bootstrap/root resolution.
• #1446 is the release/doc follow-up that explains the canonical names and restores npm publishing in the release workflows.

Canonical public identifiers now are:

• Claude marketplace/plugin install: everything-claude-code@everything-claude-code
• npm package: ecc-universal

Those names differ intentionally. Anthropic marketplace/plugin installs need the canonical plugin identifier, while npm kept the ecc-universal package name. The docs are being tightened so users do not have to guess which surface they are on.

If you are setting this up today on Windows, the safe baseline is:

1. use current main
2. treat marketplace/plugin install and npm install as different surfaces
3. prefer native .cursor/rules for Cursor and keep plugin/rules installs explicit instead of mixing old shorthand examples

[affaan-m]

Current Windows/install status:\n\n- the major install/name/GateGuard fixes are already on main\n- ecc-universal@1.10.0 is now live on npm\n- the Bash hook process-storm fix is merged on main via #1449\n\nThe one remaining install/runtime issue I am actively closing is #1454: Claude Code 2.1.x now rejects array-form hook command entries, and the self-hosted marketplace path was still shipping that old shape. I reproduced it directly and opened the fix PR here: #1462\n\nOnce #1462 lands, the remaining guidance here should just be normal install/update steps instead of active break-fix work.

[affaan-m]

Windows/install status update:\n\nThe major break-fix work from the recent install/runtime problems is now on main:\n- install/name/GateGuard fixes are merged\n- ecc-universal@1.10.0 is live on npm\n- the Bash hook process-storm fix is merged\n- the Claude Code 2.1.x hook-schema fix is merged via #1462\n\nI am still treating this as a monitored stabilization period rather than declaring every edge case solved. The remaining work now is mostly watching for OS-specific or install-path-specific reports and fixing those as they show up.\n\nIf you retry on Windows and still hit problems after updating/reinstalling, please report the exact path you used (global vs project, marketplace vs npm vs repo install) plus the exact output. That is the fastest way to separate true new bugs from stale pre-fix installs.

[affaan-m]

Windows/install status update:

Fixes already on main that directly target this lane include:

• #1539 locale-independent project detection + Windows backslash handling
• #1540 PowerShell install-hook wrapper rewrite
• #1542 PowerShell patcher rewrite
• #1490 Claude plugin manifest cleanup
• #1495 session-end filename collision isolation

Still in flight:

• #1543 Cursor project installs writing native .cursor/hooks.json and merged .cursor/mcp.json
• #1544 docs/install clarification so plugin installs are not followed by an accidental full manual install

I am treating these as release work, not backlog work. The target is a follow-up release within the next 48 hours if the remaining PRs clear. I am still watching Windows-specific edge cases after merge instead of declaring the platform fully settled too early.

[affaan-m]

Windows/Cursor install status update:\n\n- #1543 is now merged on main, so the Cursor project install lane now writes native .cursor/hooks.json and .cursor/mcp.json where Cursor actually reads them.\n- #1524 is also merged on main, covering the Claude Code v2.1.116 argv-dup workaround lane.\n- The remaining release-prep item still in flight is #1546, which fixes stale continuous-learning-v2 plugin instructions that were still telling plugin users to add old manual hook paths.\n\nSo the current Windows/Cursor state is: the major install-path fixes are already on trunk, but I am still watching for mixed old installs, stale copied files, and shell-specific edge cases instead of claiming every variation is solved.\n\nIf you are testing current main or the next release candidate, the most useful reports now are fresh repros on a clean install path, not older mixed-state setups.

[affaan-m]

Windows/Cursor install status update:\n\nThe last active release gate on this lane is now cleared. #1546 is merged on main, so the remaining plugin-install guidance mismatch in continuous-learning-v2 docs is gone as well.\n\nSo the current Windows/Cursor posture is:\n- native .cursor/hooks.json + .cursor/mcp.json project install repair is on main via #1543\n- Claude Code v2.1.116 argv-dup mitigation is on main via #1524\n- additional Windows observe-path hardening is on main via #1511\n- the plugin-vs-manual doc correction is on main via #1546\n\nI am still treating the remaining Windows-specific reports as watch-list items that need fresh repro on the current install surface, not as evidence that the release gate is still open.