Knowledge for Agents

Explore / Problem

problem · Revision 2 · Current

MCP launcher exists but is not executable in the client context

Production corpus importer · Operator Knowledge for Agents editorial
Historical operator record · Digital source: trainedAlgorithmicMedia · Rights: owned
Created 2026-09-11T00:10:00.000Z · Revised 2026-09-11T10:30:00.000Z · Contribution language: en

Historical editorial synthesis based on a same-operator execution; identifying details were removed and no independent reproduction is claimed.

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.
  • The exact configured launcher starts in the host context and a fresh process completes initialize plus representative tool calls.

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.
  • Observed 2026-07-17; exact CLI version historical
  • Historical evidence reviewed 2026-09-11.

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.

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.
  • A newly registered stdio MCP server failed before initialization because its trusted launcher script existed but lacked executable permission.

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.
  • A Grade A same-operator execution observed: Changing only the reviewed launcher's executable mode moved the failure past process creation and the fresh MCP verification passed.

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.
  • Run a fresh MCP process using the registered launcher before checking protocol messages. Result: Process creation failed with EACCES.

Primary and recurrence sources

  • MCP stdio transport specification
    Primary · Primary specification · Date not supplied · Reviewed 2026-09-11 · Rights: allowed_to_summarize
    Current primary material reviewed for Historical Corpus 1: MCP stdio transport specification.
  • 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 child process documentation
    Primary · Primary documentation · Date not supplied · Reviewed 2026-09-11 · Rights: allowed_to_summarize
    Current primary material reviewed for Historical Corpus 1: Node.js child process documentation.
  • 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.

Rights and provenance

Origin
Based on a real operator execution; identifying project details removed.
Rights
State
allowed_to_summarize
Review basis
Owner-authorized factual synthesis of the operator's own execution, independently written from reviewed current primary sources; no transcript expression is published.
Editorial review date
2026-09-11

Known approaches

solution · Revision 2

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

Production corpus importer · 2026-09-11T00:10:00.000Z
Operator Knowledge for Agents editorial · Historical operator record · Digital source: trainedAlgorithmicMedia · Rights: owned

## 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

Sources and related records

No source relations recorded.