umask 002 是协作开发项目的合理起点，使新文件默认权限为664（rw-rw-r--）、新目录为775（rwxrwxr-x），既保障组内成员可读写，又避免其他用户写入，兼顾安全与协作需求。
umask 002 是协作开发项目的合理起点
协作型项目（比如 Git 仓库、团队共享目录）需要组内成员能互相修改新创建的文件和子目录，umask 002 能让新文件默认为 664（rw-rw-r--）、新目录为 775（rwxrwxr-x），既保留组写权限，又不向“其他用户”开放写入——这是多数团队环境的安全与可用平衡点。
别用 umask 000 或 umask 006：前者导致所有新文件可被任何人写入（666），后者会意外屏蔽组读权限（660），让同事连 cat 都失败。
临时生效：确认当前会话行为再提交代码
在进入项目目录前，先运行一次：umask 002。这不会影响已有文件，只管后续 touch、mkdir、git checkout、npm install 等命令新建的内容。
验证是否生效：
-
umask应输出0002（注意前导零，部分 shell 显示为 4 位） -
touch testfile && ls -l testfile应看到权限为-rw-rw-r-- -
mkdir testdir && ls -ld testdir应看到权限为drwxrwxr-x
如果 ls -l 显示的是 644 或 755，说明当前 umask 还是 022，没改成功。
永久生效：优先改 ~/.bashrc，别碰 /etc/profile
系统级配置（如 /etc/profile）会影响所有用户，包括服务账户和 CI/CD runner，容易引发非预期权限问题。对个人开发机或团队成员账号，直接改自己家目录下的 ~/.bashrc 更稳妥。
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
操作步骤：
- 执行
echo "umask 002" >> ~/.bashrc - 立即加载：
source ~/.bashrc - 新开终端验证
umask输出是否为0002
注意：如果用了 zsh，要改的是 ~/.zshrc；某些桌面环境（如 GNOME Terminal）默认启动非登录 shell，可能不读 ~/.bashrc，此时需检查终端设置或改用 ~/.profile。
Git 和构建工具不受 umask 影响的例外情况
umask 只控制由当前进程直接创建的文件权限。但以下场景它不起作用：
-
git clone出来的文件权限继承自远程仓库对象本身，不是本地umask决定的 -
npm install、pip install下载的包，其内部脚本或 tar 解压逻辑可能硬编码了权限（比如设成755） - IDE（如 VS Code）通过自己的进程创建文件，未必继承 shell 的
umask，尤其在 GUI 启动时
这类情况得靠额外手段补救：比如用 git config core.sharedRepository group 强制 Git 仓库目录设为组可写；或在 CI 脚本开头显式加 umask 002。
真正容易被忽略的是：umask 不影响粘滞位（chmod +t）和 SGID 目录——如果你希望新文件自动继承父目录所属组，得单独给目录加 chmod g+s，这和 umask 是两套机制。
