Problem definition
When Cursor uses the Gortex MCP integration, the process can start with current working directory set to the user home (~/) instead of the opened project root. This causes Gortex MCP startup to fail at the strict entry-point handshake.
Observed logs (from Cursor MCP):
2026-05-07 17:10:06.303 [info] [V2 FSM] connection:connect_start: conn=idle,auth=unknown -> conn=connecting,auth=unknown
2026-05-07 17:10:06.303 [error] [gortex] MCP handshake failed: not a Gortex entry point: /Users/adrian is neither a workspace root (containing .gortex/workspace.toml) nor a project root (containing .gortex/). There is no walk-up. Run `gortex init` here to bind this directory as a single-project root, or create .gortex/workspace.toml to bind it as a workspace root
Error: not a Gortex entry point: /Users/adrian is neither a workspace root (containing .gortex/workspace.toml) nor a project root (containing .gortex/). There is no walk-up. Run `gortex init` here to bind this directory as a single-project root, or create .gortex/workspace.toml to bind it as a workspace root
undefined
Probable root cause
gortex install currently writes a global Cursor MCP config at ~/.cursor/mcp.json.
- The default MCP entry uses
gortex mcp --index . --watch.
- When Cursor starts this global entry without project-scoped cwd,
. resolves to ~/.
- Proxy/handshake code currently derives session cwd from
os.Getwd(), so daemon routing also inherits this wrong cwd.
- Gortex correctly rejects startup because
~/ is not a valid Gortex entry point.
Suggested implementations
-
Prefer project-local MCP for Cursor
- Do not write
~/.cursor/mcp.json by default (or for Cursor specifically).
- Keep
.cursor/mcp.json as the primary integration path via gortex init.
-
Make global Cursor MCP daemon-only if retained
- For global installs, use
gortex mcp --proxy (or equivalent daemon-only mode) instead of --index ..
- Avoid any cwd-relative index target in global config.
-
Harden cwd detection in proxy handshake
- Prefer editor-provided workspace env vars (e.g.
CURSOR_WORKSPACE) over os.Getwd() when available.
- Fallback to
os.Getwd() only when no workspace signal exists.
-
Improve install UX/docs
- Document that global Cursor MCP with
--index . can bind to home cwd and fail strict handshake.
- Recommend daemon + per-project MCP as default multi-repo setup.
Expected behavior
- Opening a project in Cursor should not fail MCP startup due to home-directory cwd.
- Gortex MCP should consistently resolve repo context from the active project workspace, or proxy through daemon without cwd-relative indexing.
Problem definition
When Cursor uses the Gortex MCP integration, the process can start with current working directory set to the user home (
~/) instead of the opened project root. This causes Gortex MCP startup to fail at the strict entry-point handshake.Observed logs (from Cursor MCP):
Probable root cause
gortex installcurrently writes a global Cursor MCP config at~/.cursor/mcp.json.gortex mcp --index . --watch..resolves to~/.os.Getwd(), so daemon routing also inherits this wrong cwd.~/is not a valid Gortex entry point.Suggested implementations
Prefer project-local MCP for Cursor
~/.cursor/mcp.jsonby default (or for Cursor specifically)..cursor/mcp.jsonas the primary integration path viagortex init.Make global Cursor MCP daemon-only if retained
gortex mcp --proxy(or equivalent daemon-only mode) instead of--index ..Harden cwd detection in proxy handshake
CURSOR_WORKSPACE) overos.Getwd()when available.os.Getwd()only when no workspace signal exists.Improve install UX/docs
--index .can bind to home cwd and fail strict handshake.Expected behavior