[Martin Bens (SpiGAndromeda)]

dev-tooling now installs and runs on OpenAI Codex from this repository's marketplace. On Claude Code the servers start and resolve the project root as before, unless the session's project directory is the plugin directory or lies inside it; the hook and text changes below apply to both hosts.

Codex packaging

• .agents/plugins/marketplace.json lists dev-tooling for codex plugin marketplace add shopwareLabs/ai-coding-tools. Codex reads it in place of .claude-plugin/marketplace.json, so only dev-tooling is listed there.
• plugins/dev-tooling/.codex-plugin/plugin.json carries the same name, version and metadata as the Claude Code manifest, except a description and keywords without the LSP, and points mcpServers at codex.mcp.json. hooks/hooks.json is discovered without a hooks field.
• codex.mcp.json starts the three servers with relative commands and cwd: ".", which Codex resolves against the plugin root; Codex does not expand ${CLAUDE_PLUGIN_ROOT} in this file. Codex starts MCP servers with a small default environment (HOME, PATH, SHELL, USER, TMPDIR and a few more) plus only the variables an entry declares, so each entry forwards PROJECT_ROOT, its MCP_*_TOOLING_CONFIG override, MCP_LOG_STDERR, MCP_EXTRA_LOG_FILE, the DOCKER_* variables, the docker compose selectors (COMPOSE_PROJECT_NAME, COMPOSE_FILE, COMPOSE_PROFILES, COMPOSE_PATH_SEPARATOR), the Vagrant settings (VAGRANT_CWD, VAGRANT_HOME, VAGRANT_DOTFILE_PATH, VAGRANT_VAGRANTFILE, VAGRANT_DEFAULT_PROVIDER) and SSH_AUTH_SOCK.

Project root on Codex

With cwd: "." a server starts in the plugin directory and receives no project directory. shared/launch.sh starts such a server unbound: it loads no configuration, answers initialize and tools/list, and every tool except set_project_root and cwd refuses with a message that names set_project_root. cwd reports the unbound state.

While unbound, set_project_root accepts the absolute path of a plain project directory, loads its configuration, validates scopes and environment, and binds the server to it once. The bind stores the physical path, and a relative MCP_*_TOOLING_CONFIG resolves against that root. Each request runs in its own subshell, so the bind is a launch record in the server's state file, and every tool call restores the bound state from it. After the bind, the existing linked-worktree rules apply.

The docs recommend this on-demand bind, which the SessionStart directive drives once the plugin hooks are trusted. Exporting PROJECT_ROOT before starting Codex binds at startup instead. The docs warn that Codex's long-lived app-server process keeps an exported value, so later sessions it serves start bound to that path until the process restarts.

On both hosts, set_project_root with the launch root now clears the sticky root, as omitting the argument does. A server started with a project root refused that call before.

A relative MCP_*_TOOLING_CONFIG is now made absolute when the server starts or binds, and every later call sees the absolute path. Before, a server started in the project lost the override on a call targeting a linked worktree, so phpstan_analyze ran without the project's --configuration.

To support the unbound start, the computation of the launch root's common git directory moved out of worktree_state_init into worktree_launch_common_init, which each server.sh calls when the server starts bound. The set_project_root description in all three tools.json files now covers both cases.

Hooks

• The hook library resolves the project directory from CLAUDE_PROJECT_DIR and, when that is unset as on Codex, from the hook input's .cwd. The library is template-synced, so templates/hooks-shared/common.sh and shopware-env's copy carry the same change.
• Block messages name the tool and its server (they read "Use phpstan_analyze on the php-tooling MCP server instead!") instead of mcp__<server>__<tool>, a form that neither host produces for a plugin install. This covers shopware-env's check-lifecycle-tools.sh as well.
• The PostToolUse matcher of the PHPStan baseline hook never matched on Claude Code plugin installs, which name the tool mcp__plugin_dev-tooling_php-tooling__phpstan_analyze. It now matches that name and the Codex name mcp__php_tooling__phpstan_analyze.
• Codex gets its own SessionStart directives (mcp-tool-directives-codex.md), selected when CLAUDE_PROJECT_DIR is unset. They leave out the dev-tooling-runner subagent and EnterWorktree/ExitWorktree, which Codex does not have. On that path the hook appends a section that names the session directory from the hook input's .cwd and tells the model to call set_project_root with it when a tool reports no project root; that section is emitted even when enforce_mcp_tools is false in every config present.
• The Claude Code directives now name the server of every tool they mention. Both directive files say to run worktree_prepare on the server a refusal names, since a ludtwig refusal for a missing vendor/ names php-tooling.

Claude Code only

The phpactor LSP (.lsp.json), the dev-tooling-runner agent and the EnterWorktree/ExitWorktree reminder hook have no Codex equivalent and are documented as Claude Code only.

Other changes

• plugin-updating bumps .codex-plugin/plugin.json together with .claude-plugin/plugin.json, through one rewrite function, and checks the rewritten version of every manifest it touches.
• CI runs the BATS job when only .agents/** or .claude-plugin/** changes.
• The root README.md lists bash 4.1+ (macOS's stock /bin/bash is 3.2) among dev-tooling's prerequisites.
• Releases: dev-tooling 4.1.0, shopware-env 1.4.1 (block messages and the .cwd fallback), plugin-setup 1.0.3 (refreshed copy of dev-tooling's SETUP.md).

Related: #189 (merged config temp file left behind at server start).

🤖 Generated with Claude Code

[github-actions]

Agent Skills Export

Built 7 skill packages:

• feature-branch-pr-writing
• adr-writing
• commit-message-writing
• ci-log-interpretation
• pr-description-writing
• structuring-documentation
• release-info-writing