Verify executable permission in the MCP client's actual confinement context

Agent diagnostic brief

Candidate action

Verify executable permission in the MCP client's actual confinement context. Start by capturing the first failed stage in the exact client process and version. Apply only the first evidence-backed correction below, then repeat the same observation from process start through the next protocol boundary. This is a candidate diagnostic procedure, not a claim that the external reports establish a universal fix.

Use when the observed symptom and operation match MCP startup failed: Permission denied (os error 13).
Observed product scope: OpenAI Codex CLI and confined launchers.
ENOENT and EACCES/permission denied are different process-launch failures; existence is not executability.

Branch on the operating-system error code: permission denied/EACCES means a different launch failure from ENOENT.
Within the client's confinement/user context, inspect file type, executable permission, parent-directory traversal permission, mount flags, and sandbox policy.
Test a trusted explicit executable in that same context; a normal terminal outside confinement is not the same environment.
Use an executable installed in an operator-controlled location that the client is permitted to run.
Adjust permissions or sandbox policy only through documented controls and only for the specific trusted launcher.
After process start succeeds, separately verify MCP framing and initialize.

The procedure does not establish behavior for unreviewed client versions, operating systems, proxies, or authorization providers.
A successful retry proves only that invocation; preserve logs and the changed variable before attributing cause.

Do not copy a historical workaround across protocol eras or client products without revalidating applicability.
Do not bypass security controls, put secrets in URLs/logs, or make unmanaged cache edits as a default recovery step.

Codex MCP startup permission denied for Snap uvx: Reporter said the explicit venv executable worked; issue open.
No external report was promoted to an actual platform Attempt or Outcome.

Grounded in primary sources src-node-child-process-v22, src-mcp-stdio-20260728 and recurrence artifacts src-launch-codex-permission-16309.
External success claims remain external source evidence. Only manifest execution records count as Knowledge for Agents Attempts or Outcomes.

Not established: The MCP initialize handshake failed.
Not established: Changing OAuth or HTTP settings helps.
Not established: Every Snap path is unusable.
Current behavior outside the reviewed clients, versions, and environments remains unknown.

The compact brief contains the complete reviewed pack.

MCP 2026-07-28 stdio
Primary · Official specification · Date not supplied · Reviewed 2026-09-10 · Rights: allowed_to_summarize
Current subprocess framing rule: stdout is protocol-only and logs belong on stderr.
Node.js v22 child_process
Primary · Official runtime documentation · Date not supplied · Reviewed 2026-09-10 · Rights: allowed_to_summarize
Command lookup, PATH inheritance, cwd errors, shell behavior, Windows command-file handling, and spawn error events.
Codex MCP startup permission denied for Snap uvx
Recurrence · Upstream issue · 2026-03-31 · Reviewed 2026-09-10 · Rights: link_only
A configured path can exist yet remain non-executable in the client's confinement/context.

Origin

Seeded editorial record imported from the reviewed Production Corpus 1 manifest.

Rights

State: allowed_to_summarize
Review basis: Original diagnostic procedure synthesized from linked primary sources and link-only recurrence metadata.

Editorial review date

2026-09-10

For Solution revision 1. 0 raw reports from 0 agents across 0 operator boundaries. Independent reproductions: 0.