Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Security] Ship a dedicated/bundled Node binary so macOS TCC permissions (FDA, Accessibility) are scoped to OpenClaw only [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#69799•Fetched 2026-04-22 07:48:12
View on GitHub
Comments
1
Participants
2
Timeline
1
Reactions
0
Author
zhendalfzhendalf
Participants
dengluozhangdengluozhangzhendalfzhendalf
Timeline (top)
commented ×1

Error Message

  • #69561 — docs request to warn about this

Root Cause

Full Disk Access is one of the most powerful macOS permissions — it bypasses SIP protections and grants read access to ~/Library/Mail, iCloud Drive, ~/Library/Messages, etc. Users who want to use OpenClaw's iMessage/Mail integrations currently have no way to grant this without also granting it to their entire npm ecosystem.

Fix Action

Fix / Workaround

Options:

  1. Bundle Node inside an .app wrapper — standard macOS app bundle with a signed binary. Cleanest UX; macOS shows "OpenClaw" in Privacy & Security, not "node".
  2. Install a dedicated Node binary at a well-known path (e.g. /opt/openclaw/bin/node) during setup, separate from the system/nvm Node.
  3. Document a workaround for users today: install a dedicated Node via nvm/standalone for OpenClaw use, grant FDA only to that path.
RAW_BUFFERClick to expand / collapse

Problem

When users grant Full Disk Access (or Accessibility) to OpenClaw on macOS, they must grant it to the shared node binary (e.g. /usr/local/bin/node or an nvm-managed path). macOS TCC has no mechanism to scope that permission to OpenClaw specifically — the grant applies to every process that runs through the same binary, including:

  • All globally installed npm packages
  • All node_modules in any project on the machine
  • Any supply-chain-compromised dependency

This means a malicious or compromised npm package in any unrelated project could inherit Full Disk Access simply because OpenClaw asked for it.

Related Issues

  • #7227 — same class of problem for Accessibility permissions
  • #69561 — docs request to warn about this
  • #22179 — TCC permissions break when node binary path changes on update

Proposed Solution

Ship OpenClaw with its own bundled or dedicated Node binary, similar to how Electron apps bundle their own Node runtime. This would allow users to grant macOS TCC permissions (FDA, Accessibility, Contacts, etc.) to that specific binary, scoping the grant to OpenClaw only.

Options:

  1. Bundle Node inside an .app wrapper — standard macOS app bundle with a signed binary. Cleanest UX; macOS shows "OpenClaw" in Privacy & Security, not "node".
  2. Install a dedicated Node binary at a well-known path (e.g. /opt/openclaw/bin/node) during setup, separate from the system/nvm Node.
  3. Document a workaround for users today: install a dedicated Node via nvm/standalone for OpenClaw use, grant FDA only to that path.

Option 1 is the gold standard. Even Option 2 would be a meaningful improvement for security-conscious users.

Why This Matters

Full Disk Access is one of the most powerful macOS permissions — it bypasses SIP protections and grants read access to ~/Library/Mail, iCloud Drive, ~/Library/Messages, etc. Users who want to use OpenClaw's iMessage/Mail integrations currently have no way to grant this without also granting it to their entire npm ecosystem.

Environment

  • macOS (all versions with TCC)
  • OpenClaw installed via npm (global)
  • Any Node install path (Homebrew, nvm, system)

extent analysis

TL;DR

Ship OpenClaw with its own bundled or dedicated Node binary to scope macOS TCC permissions to OpenClaw only.

Guidance

  • Consider bundling Node inside an .app wrapper for the cleanest UX, allowing macOS to display "OpenClaw" in Privacy & Security settings.
  • Installing a dedicated Node binary at a well-known path during setup is a viable alternative, improving security for users.
  • Documenting a workaround for users to install a dedicated Node via nvm/standalone for OpenClaw use can provide a temporary solution.
  • Evaluate the trade-offs between the proposed options, considering factors like user experience, security, and maintenance.

Example

No code snippet is provided as the issue focuses on high-level solutions rather than specific code changes.

Notes

The proposed solutions aim to address the security concern of granting Full Disk Access to the shared node binary, which applies to all processes running through it. The chosen solution should balance security, user experience, and maintainability.

Recommendation

Apply workaround: Ship OpenClaw with its own bundled or dedicated Node binary, as this approach directly addresses the security concern by scoping permissions to OpenClaw only, without relying on external factors like user configuration or third-party updates.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#dependency conflict#environment setup#docker error#permission error#memory optimization

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING