Agent diagnostic brief
Exact symptom
- MCP startup failed: Permission denied (os error 13)
Where it has been observed
- Ubuntu; Snap confinement; uvx launcher
Likely distinct causes
- The configured launcher path is not executable or accessible within the client context/confinement.
How to distinguish them
- 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.
Current approaches
- Verify executable permission in the MCP client's actual confinement context (solution-launch-permission-denied, revision 1).
Known obsolete approaches
- Do not apply historical protocol or client workarounds without checking the current version boundary.
- Do not disable authentication, issuer/audience checks, schema validation, sandboxing, or enterprise policy merely to suppress the symptom.
Versions and freshness
- Observed in Codex CLI 0.114.0 on Ubuntu with a Snap uvx path; current cause is environment-specific.
- Editorial and primary-source review date: 2026-09-10.
What remains unknown
- 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.
Deeper evidence
Problem
- MCP launcher exists but is not executable in the client context
Observed symptom
- The host reports Permission denied (os error 13) before the stdio server can initialize.
- Observed in 1 reviewed public artifact; this is not a claim that only that many reports exist.
Operator goal
- start stdio MCP server using stdio.
Current understanding
- ENOENT and EACCES/permission denied are different process-launch failures; existence is not executability.
- The configured launcher path is not executable or accessible within the client context/confinement.
Known limitations
- Applies only to OpenAI Codex CLI and confined launchers and the stated version/environment boundary until current behavior is rechecked.
- A source-reported workaround is evidence from that report, not a Knowledge for Agents execution or universal Outcome.
Known negative results
- 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.
Primary and recurrence sources
- MCP 2026-07-28 stdio
Current subprocess framing rule: stdout is protocol-only and logs belong on stderr. - Node.js v22 child_process
Command lookup, PATH inheritance, cwd errors, shell behavior, Windows command-file handling, and spawn error events. - Codex MCP startup permission denied for Snap uvx
A configured path can exist yet remain non-executable in the client's confinement/context.
Rights and provenance
- Origin
- Seeded editorial record imported from the reviewed Production Corpus 1 manifest.
- Rights
- State
- allowed_to_summarize
- Review basis
- Original Knowledge for Agents synthesis; linked external reports remain link_only and no issue/forum prose is copied.
- Editorial review date
- 2026-09-10
Known approaches
solution · Revision 2
Verify executable permission in the MCP client's actual confinement context
## 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.
## Applicability
- 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.
- Historical execution boundary: Codex CLI and MCP; stdio launcher.
## Procedure
- 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.
- Set executable mode on the specific reviewed launcher and repeat the fresh-process checks. Verify: The process started and all intended read-only tools passed their verification set.
## Limitations
- 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.
## Obsolete approaches
- 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.
## Negative results
- 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.
- Run a fresh MCP process using the registered launcher before checking protocol messages. Result: Process creation failed with EACCES.
## Evidence boundary
- 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.
- A Grade A same-operator execution on 2026-07-17 observed: Changing only the reviewed launcher's executable mode moved the failure past process creation and the fresh MCP verification passed.
- This is not an independent reproduction.
## What remains unknown
- 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.
- Independent reproduction by another operator remains unestablished.
- Applicability
- State
- partial
- Text
- Applies only when the first failed stage matches this record in OpenAI Codex CLI and confined launchers.
- Facts
- Component
- filesystem execution permission/sandbox
- Operation
- start stdio MCP server
- Protocol
- stdio
- Provenance disclosure
- Based on a real operator execution; identifying project details removed.
- Historical date
- 2026-07-17
- Verification grade
- A
- Operator relationship
- same_operator
- Independent reproduction
- false
- Pack
- 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.
- Applicability
- 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.
Historical execution boundary: Codex CLI and MCP; stdio launcher. - Steps
- 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.
Set executable mode on the specific reviewed launcher and repeat the fresh-process checks. Verify: The process started and all intended read-only tools passed their verification set. - Limitations
- 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. - Obsolete approaches
- 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. - Negative results
- 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.
Run a fresh MCP process using the registered launcher before checking protocol messages. Result: Process creation failed with EACCES. - Evidence boundary
- 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.
A Grade A same-operator execution on 2026-07-17 observed: Changing only the reviewed launcher's executable mode moved the failure past process creation and the fresh MCP verification passed.
This is not an independent reproduction. - What remains unknown
- 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.
Independent reproduction by another operator remains unestablished.
- Rights
- State
- allowed_to_summarize
- Review basis
- Original diagnostic procedure synthesized from owner-authorized execution facts and linked current primary sources; no private source code, logs, or transcript expression is published.
- Source ids
- src-node-child-process-v22
src-mcp-stdio-20260728
src-launch-codex-permission-16309
src-node-child-process-current
src-mcp-stdio-20251125 - Editorial review date
- 2026-09-11
- Seo metadata
- Meta title
- Verify executable permission in the MCP client's actual confin… | Knowledge for Agents
- Meta description
- Candidate procedure for EACCES: Permission denied, now linked to a Grade A same-operator execution with current sources, limits, and unknowns.
- Historical execution
- Disclosure
- Based on a real operator execution; identifying project details removed.
- Operator relationship
- same_operator
- Independent reproduction
- false
- Problem id
- problem-launch-permission-denied
Page 1 · 1 children total
Sources and related records
No source relations recorded.