Sensitive files

[nf-matt]

Hi, awesome project, and you're off to a great start! This has the potential to be a lot better than other sandboxing tools.

I am stuck trying to do one common thing. I have been unable to make git remotes work, either with SSH (preferred) or HTTPS. HTTPS adds credentials access "fun". SSH is what I would prefer to do, but no matter what I can't make the necessary files accessible.

I tried every way I could think of (--allow/--read combinations of files and directories) to override the block on keys or sensitive files, which obviously it needs. Any suggestions?

[lukehinds]

hi @nf-matt , thanks for the kind words! we are going to introduce overrides , I will see if I can expedite this in for the next release

[nf-matt]

It looks like I managed to work around the issue. Specifically I needed a way to give SSH access for git and gh.

My failed attempts:

❌ Try to override ~/.ssh/known_hosts and ~/.ssh/some-key*
❌ Try to create a new ~/.seatbelt directory and symlink the files from ~/.ssh

My success:

✅ Create a new ~/.seatbelt directory and copy the files from ~/.ssh

With a little digging, I read that seatbelt operates at the kernel level, and doesn't care about symlinks. It looks at the final object, and will for sure block what nono considers to be off-limits. That's probably a good thing because it would make it harder to create a backdoor path to a file that should be protected.

What worked specifically for git and gh after copying the key/pub to ~/.seatbelt (didn't copy known_hosts because git doesn't need most of it):

SEATBELT_DIR="${HOME}/.seatbelt"
GH_KEY="${SEATBELT_DIR}/.ssh/id_ed25519_github"
GH_PUB="${SEATBELT_DIR}/.ssh/id_ed25519_github.pub"
GH_CONFIG="${HOME}/.config/gh"

GIT_SSH_COMMAND="ssh \
  -l git \
  -o IdentityFile=${GH_KEY} \
  -o StrictHostKeyChecking=accept-new \
  -o UserKnownHostsFile=${SEATBELT_DIR}/.ssh/known_hosts \
  -o GlobalKnownHostsFile=/dev/null"

nono run --profile claude-code \
  # other args
  --read "${SEATBELT_DIR}" \
  --allow-file "${SEATBELT_DIR}/.ssh/known_hosts" \
  --read-file "${GH_KEY}" \
  --read-file "${GH_PUB}" \
  --read "${GH_CONFIG}" \
  -- env GIT_SSH_COMMAND="${GIT_SSH_COMMAND}" claude "$@"

Thanks again, great tool!

---

EDIT: known_hosts failed to update at first, but the git worked anyway. I did touch known_hosts and restarted the nono/claude session and it seemed to take.

[pierres]

Not sure if that's going to be similar on Mac, but I guess when using a ssh agent one just needs to allow access to it's socket and maybe the known hosts file: --allow-file $SSH_AUTH_SOCK --allow-file ~/.ssh/known_hosts. It might be a little more secure than providing the plain keys to the agent.

[nf-matt]

Oh I like that. Thanks for the suggestion. I'll give that a shot.

[nf-matt]

What would keep this codebase from accessing sockets when using this script to start claude?

The primary blocker: ProxyOnly mode activates (deny network*)

The claude-code profile sets "network_profile": "developer". In NetworkConfig::has_proxy_flags() (profile/mod.rs:452), any non-None network_profile returns true, triggering ProxyOnly mode.

In macos.rs:generate_profile (macos.rs:452-465), ProxyOnly mode emits:
(deny network*)
(allow network-outbound (remote tcp "localhost:"))
(allow system-socket (socket-domain AF_INET) (socket-type SOCK_STREAM))
(allow system-socket (socket-domain AF_INET6) (socket-type SOCK_STREAM))

The (deny network*) rule in Seatbelt covers all address families — including AF_UNIX. Connecting to a Unix domain socket goes through network-outbound, which is denied here. So both ${SSH_AUTH_SOCK} and /tmp/cmux.sock would be blocked at the socket-connect level despite having file-level access granted via --allow-file.

Why --allow-file "${SSH_AUTH_SOCK}" isn't enough

--allow-file emits file-read* and file-write* rules for the socket's path (capability_ext.rs:121-127). But connecting to a Unix domain socket
requires:

1. File permissions on the path — ✅ covered
2. system-socket (socket-domain AF_UNIX) — ❌ not allowed in ProxyOnly mode
3. network-outbound — ❌ blocked by (deny network*)

A potential inconsistency in the profile generation

There's an unconditional (allow system-socket) emitted at macos.rs:348 — before the network rules. In ProxyOnly mode, the narrower AF_INET/AF_INET6 rules added later are intended to scope it down. But since the earlier broad (allow system-socket) already matches all socket types, and Seatbelt's rule ordering is last-match-wins for equal specificity, the broad allow at the top may actually preempt the intended TCP-only scoping. That's potentially a bug in the ProxyOnly path — but it only matters for socket creation, not for connect(). The (deny network*) still prevents the actual connection.

Summary

What blocks socket access	Why
(deny network*) from ProxyOnly mode	developer network profile → has_proxy_flags() → NetworkMode::ProxyOnly
system-socket not allowed for AF_UNIX	ProxyOnly only permits AF_INET/AF_INET6 (though the unconditional broad allow at line 348 may override this
--allow-file insufficient alone	Grants file-level access, not network-outbound for the connect syscall

If you want SSH agent and cmux socket access to work, you'd need to avoid ProxyOnly mode (remove network_profile from the profile or override it), or the sandbox would need an explicit Seatbelt rule like (allow network-outbound (local unix-socket)) — which the current profile generator doesn't produce.

---

Option 2 — Proper approach: CapabilitySet::allow_unix_sockets + --allow-socket flag

This would be ~4 files touched:

1. capability.rs — add allow_unix_sockets: bool field to CapabilitySet, with builder method allow_unix_sockets()
2. macos.rs — in the ProxyOnly branch, check caps.allow_unix_sockets() and conditionally emit:
   (allow network-outbound (local unix-socket))
   (allow system-socket (socket-domain AF_UNIX))
3. cli.rs — add --allow-socket flag (a path argument)
4. capability_ext.rs — in add_cli_overrides, when --allow-socket paths are present, call caps.allow_unix_sockets() and also add the path as a file
   capability

This way --allow-socket "${SSH_AUTH_SOCK}" would:

• Grant file-read*/file-write* on the socket path (like --allow-file)
• Emit the AF_UNIX Seatbelt rules only when explicitly requested

Option 2 is the right design — it's opt-in and keeps the ProxyOnly security intent intact.

[nf-matt]

I had claude create a new claude-code-local profile that is the same as what nono produces, minus the proxy restriction. The only delta from claude-code is "network": { "block": false } — no network_profile key. That leaves NetworkMode::AllowAll, so (allow network-outbound) is emitted and Unix domain sockets work.

Save it to ~/.config/nono/profiles/claude-code-local.json and use --profile claude-code-local in your script (replacing --profile claude-code). You keep all the same deny groups, filesystem grants, and hooks — just without the proxy's network filtering.

{
  "meta": {
    "name": "claude-code-local",
    "version": "1.0.0",
    "description": "claude-code without proxy filtering, for local socket access"
  },
  "security": {
    "groups": [
      "deny_credentials",
      "deny_keychains_macos",
      "deny_keychains_linux",
      "deny_browser_data_macos",
      "deny_browser_data_linux",
      "deny_macos_private",
      "deny_shell_history",
      "deny_shell_configs",
      "system_read_macos",
      "system_read_linux",
      "system_write_macos",
      "system_write_linux",
      "user_tools",
      "homebrew",
      "dangerous_commands",
      "dangerous_commands_macos",
      "dangerous_commands_linux",
      "user_caches_macos",
      "node_runtime",
      "rust_runtime",
      "python_runtime",
      "vscode",
      "unlink_protection"
    ]
  },
  "filesystem": {
    "allow": [
      "$HOME/.claude"
    ],
    "read": [
      "$HOME/.local/share/claude"
    ],
    "allow_file": [
      "$HOME/.claude.json",
      "$HOME/.claude.json.lock"
    ],
    "read_file": [
      "$HOME/Library/Keychains/login.keychain-db",
      "$HOME/.gitconfig",
      "$HOME/.gitignore_global",
      "$HOME/.config/git/ignore"
    ]
  },
  "network": {
    "block": false
  },
  "workdir": {
    "access": "readwrite"
  },
  "hooks": {
    "claude-code": {
      "event": "PostToolUseFailure",
      "matcher": "Read|Write|Edit|Bash",
      "script": "nono-hook.sh"
    }
  },
  "undo": {
    "exclude_patterns": [
      "node_modules",
      ".next",
      "__pycache__",
      "target"
    ],
    "exclude_globs": [
      "*.tmp.[0-9]*.[0-9]*"
    ]
  },
  "interactive": true
}

[jdumas]

Hi. I'm stumbling upon issues like these, and I was wondering if we could have some official guidance/documentation on best practices related to git/ssh operations? I'm a bit tired of banging my head against Claude trying to hallucinate what's the best way to wrangle the config file to do what we want, so some guidance on best practices would be nice (I'm also hitting issues like #1695 on macOS). Ideally this should cover simple cases from keys with empty passphrase that don't require a ssh-agent, to more complex scenarios.

[lukehinds]

@jdumas there is some good examples of tool sandboxing contributed by the datadog folks, does this help: https://github.com/nolabs-ai/nono/tree/main/tool-sandbox-examples/git-ssh