Use Glider with Codex

Codex Setup

Configure Glider with Codex CLI, Codex IDE extension, and Codex app.

Codex

Prerequisite: .NET 10 SDK must be installed before running dotnet tool install --global glider.

dotnet tool install --global glider

Codex starts stdio MCP servers through the configured command. Make sure glider is available on PATH.

# bash/zsh
export PATH="$PATH:$HOME/.dotnet/tools"
which glider

Create .codex/config.toml in each worktree root. Codex loads project configuration for trusted projects. Replace src/App.slnx with your solution path relative to that root. Launch the MCP server from the worktree root. Use ~/.codex/config.toml only when you want user-wide configuration. Codex MCP docs: developers.openai.com/codex/mcp.

# .codex/config.toml in each worktree
# Launch the MCP server from that worktree root.
[mcp_servers.glider]
command = "glider"
args = ["--solution", "src/App.slnx", "--default-timeout", "30m"]
startup_timeout_sec = 30
tool_timeout_sec = 1800

In the Codex app, open Settings > Integrations & MCP to add or manage the same MCP server configuration. Advanced edits still go through config.toml.

The Glider plugin is published from glidermcp/glidermcp.com and bundles the product skill plus stdio MCP config. After adding the marketplace, install glidermcp from the Codex app Plugin Directory or from the CLI /plugins browser.

codex plugin marketplace add glidermcp/glidermcp.com

If you prefer Streamable HTTP, start Glider yourself and configure Codex with http://localhost:5001/mcp. Use only one glider server entry unless you intentionally want separate stdio and HTTP configs.

glider --transport http --default-timeout 30m

# ~/.codex/config.toml
[mcp_servers.glider]
url = "http://localhost:5001/mcp"
tool_timeout_sec = 1800

Start a new Codex session, then run /mcp to confirm the server is available.

codex
# Then run: /mcp

Add --solution <path> to the launch arguments in the configuration above so Glider loads your solution or project (a .sln, .slnx, or .csproj file) at startup, instead of waiting for the agent to call load. With it set, server_status shows the workspace as loaded — or, on a large workspace, still loading in the background under workspaceLoading — from the first message, so the agent can wait for that load to finish instead of stopping with a "No solution loaded. Use load first." message and reaching for text search. Put the flag after -- for claude mcp add, add it to the args array in JSON and Codex TOML configs, or to the single command array for OpenCode. For worktrees, prefer a relative path and launch the server from the selected worktree root. Relative paths use the server launch directory, not the config file directory. An absolute path intentionally pins one checkout.

# From the selected worktree root; replace src/App.slnx with your solution path.
glider --solution src/App.slnx --default-timeout 30m
# Add --workspace <dir> to watch a different root, or --no-watch to disable file watching.

Use a project-local config: Claude Code .mcp.json, Codex .codex/config.toml (trusted projects), Cursor .cursor/mcp.json, or VS Code .vscode/mcp.json. Include portable config files in version control, or copy local config files into each worktree. Git does not copy ignored files. Use absolute paths only when you intentionally want one fixed checkout, such as a global Claude Desktop configuration.

Open the client at the selected worktree root. Relative server arguments use the server launch directory, not the config file directory. Project scope alone does not guarantee that directory. If the client starts elsewhere, configure its MCP working directory or use a Git-root launcher.

Run git rev-parse --show-toplevel in the client terminal, then ask server_status for the server workspace. Confirm that the loaded solution or workspace belongs to that worktree before you query or change code. For a wrong root, explicitly load the intended workspace or restart the server with the correct path.

An existing HTTP server keeps its own workspace when the client changes directories. Use separate servers and ports for simultaneous worktrees.

git rev-parse --show-toplevel

Use this alternative when the client starts inside the worktree but below its root. It requires Git and a POSIX shell. Replace the existing server entry; do not add a second instance. For Glider, replace src/App.slnx with your solution path. On Windows, use the relative configuration above and set the MCP launch directory to the worktree root. This launcher cannot identify your worktree if the client starts outside its directory tree.

# .codex/config.toml in each worktree
[mcp_servers.glider]
command = "sh"
args = ["-c", "repo_root=$(git rev-parse --show-toplevel) && exec glider --solution \"$repo_root/src/App.slnx\" --default-timeout 30m"]
startup_timeout_sec = 120
tool_timeout_sec = 1800

After connecting Glider, add this product-specific instruction to your MCP client system prompt or project instructions so the agent chooses the right tool surface first.

When working in C#/.NET workspaces, prefer glider mcp semantic tools for symbol identity, code relationships, diagnostics, dependencies, impact analysis, and preview-first refactors. Use Scout for repository retrieval and raw text questions. Use the .NET CLI for build and test commands. Preload the solution with --solution, or call load before semantic queries.