这类问题我又碰上了一次。给同事分配 developer 角色，登录后左侧用量菜单是灰的，直接打开 /usage 返回 403，响应体是 You do not have permission to perform this action，同组另一个 admin 账号打开正常。
第一反应是「角色继承链没生效，父角色权限没带下来」，验证下来不成立。
真正麻烦的地方在于，几个原因的现象几乎一样。developer 角色不含 api.usage.read 这类只读权限；成员拿的是项目级角色，组织级页面需要组织级角色；浏览器缓存了上一次的权限快照。
上来先列出该角色的实际权限项
curl -s https://api.openai.com/v1/organization/roles/role_dev -H "Authorization: Bearer $ADMIN_KEY" | jq '.permissions[]'给角色补上用量读取权限
curl -X PATCH https://api.openai.com/v1/organization/roles/role_dev -H "Authorization: Bearer $ADMIN_KEY" -d '{"permissions":["api.read","api.usage.read"]}'然后让成员退出后重新登录拿新令牌
curl -s https://api.openai.com/v1/organization/users/user_123 -H "Authorization: Bearer $ADMIN_KEY" | jq '.roles'等前面都确认过，再用成员令牌直接打用量接口验证
curl -s -o /dev/null -w '%{http_code}\n' 'https://api.openai.com/v1/organization/usage/completions?start_time=1730000000' -H "Authorization: Bearer $MEMBER_KEY"恢复的判定其实很直接。成员重新登录后 /usage 返回 200，菜单可点，同一令牌连续请求三次都不再出现 403。
容易忽略的是，角色改完必须让成员重新登录，旧的会话令牌里还带着旧权限声明，否则会以为是权限没生效又改一遍。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。