[FEATURE] Setting to trust specific network paths (Linux /net automounts) so file reads stop prompting
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
On Linux clusters where the shared NFS filer is reached through the autofs -hosts map, all code and data live under /net/<host>/..., including the session's working directory. Claude Code treats every such path as a network path, so every Read, Grep and Glob asks for permission, even reads inside the working directory.
Nothing a user can configure skips this prompt:
- allow rules such as
Read(//**)orRead(//net/mraid20/**); - PreToolUse hooks that return
allow; additionalDirectoriesand--add-dir, which refuse/netpaths;- auto mode, where the prompt goes to the user instead of the classifier.
As a result, auto mode cannot run unattended for anyone whose files are on such a filer. On our cluster (RHEL 8, filer mraid20, files under /net/mraid20/ifs/wisdom/tanay_lab) every session stops on almost every tool call. We cannot change the layout: IT will not add a mount outside /net, and users have no root.
The docs give two reasons for the check: looking up a /net path can contact the host it names, and on Windows that contact can send credentials. In this setup the -hosts map is already mounted, and the host is the filer that the session already runs from, so neither reason applies.
This first appeared as a regression in 2.1.191 (#77571). A maintainer reproduced it there, and the stale bot then closed it. Since 2.1.292 the docs describe the behavior as intended, so I am filing this as a feature request rather than a bug. Seen on 2.1.296.
Proposed Solution
A user-level or managed setting that lists network path prefixes the user trusts, for example:
{
"permissions": {
"trustedNetworkPaths": ["/net/mraid20"]
}
}
Reads under a listed prefix would then follow the normal rules for local paths: no prompt inside the working directories, and allow rules apply outside them. It would also be good if a listed prefix could be used as a working directory or in additionalDirectories. Paths that are not listed keep the current check.
The setting should not be accepted from project settings (.claude/settings.json in a repo), for the same reason autoMode is not.
Alternative Solutions
- Exempt the working directory's host. Claude Code already accepts a
/net/<host>path as the working directory when it is launched from under that host's automount. The read check could exempt that host in the same way. This needs no new setting, but it does not cover a second filer. - Respect explicit allow rules for network paths on Linux. This is less explicit than a dedicated setting.
- Our current workaround. A user-level rclone FUSE mount of the same tree at a local path (
/local_data/<user>/tanay_lab), plus PreToolUse/PostToolUse hooks that rewrite every file-tool path to the mount and restore file modes after edits. Reads and edits then run without prompts. This shows the check looks only at the path, and it works, but it puts every file operation through a FUSE layer only to get past a check that protects nothing in this setup.
Priority
High - Significant impact on productivity
Feature Category
Configuration and settings
Use Case Example
- I start Claude Code in auto mode in
/net/mraid20/ifs/wisdom/tanay_lab/data/users/<me>/proj/<project>and ask it to run an analysis and report back. - It reads source files, READMEs and the PNG figures that the analysis wrote. Today each read stops and waits for me.
- With
trustedNetworkPaths: ["/net/mraid20"]in~/.claude/settings.json, those reads would run, and the auto-mode classifier would still review shell commands and other actions as usual.
Additional Context
- Docs that describe the behavior: Network paths, Working directory is a network path.
- Original regression report and reproduction: #77571.
- Environment: Linux (RHEL 8.10), Claude Code 2.1.296 native install, autofs
-hostsmap on/net.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗