{"version":"2.1.246","anchor":"hook-and-mcp-program-trust-checks-look-at-a-second-path","canonical_anchor":"hook-and-mcp-program-trust-checks-look-at-a-second-path","heading":"Hook and MCP program trust checks look at a second PATH","tier":"internal","area":"Hooks","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.246\/e\/hook-and-mcp-program-trust-checks-look-at-a-second-path","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.246","markdown":"### Hook and MCP program trust checks look at a second PATH\n\nHook and MCP programs are checked against two PATHs, and any mismatch counts as risky.\n\n**What**\n\nThe check deciding whether a hook command or MCP stdio program is unreadable or in reach now resolves the program against both the base environment PATH and a separate MCP-specific path, and treats any disagreement between the two as in reach. Interpreted programs are probed as well.\n\n**Details**\n\n- The shell prefix used to expand a hook command now comes from the calling context instead of being read from `CLAUDE_CODE_SHELL_PREFIX` in the environment.\n- The old launch-directory reach builder and its `HostPathRefused` error were removed, replaced by a routine that decides which settings scopes are in reach and treats a file with more than one hard link as reachable.\n\n**Evidence**\n\n`program_in_reach`\n\n- Area: Hooks\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 3\/5"}