中风险
无关键词筛选可批量枚举同事并暴露不必要的个人与关系数据
原文依据：5 处发现了什么
文档允许只用布尔筛选、无需姓名或邮箱关键词，示例会列出所有曾聊过且已离职的同事。查询结果还可包含个人邮箱、部门、签名、账号状态以及是否聊过和 P2P 会话 ID。虽然受当前账号可见范围限制，这仍可能远超完成一次联系人解析所需的数据。
为什么需要注意
若代理对含糊请求执行此类广泛搜索，结果可能在模型上下文、终端输出或后续回复中暴露同事的联系方式、组织归属、离职状态和联系关系。批量 open_id 查询最多可一次回填 100 人，扩大单次泄露范围。
文档明确允许不提供姓名、邮箱或 ID，仅凭布尔筛选进行查询，并给出枚举所有“聊过天的离职同事”的可执行示例。返回契约包含个人/企业邮箱、部门、签名、账号状态，以及 P2P 会话 ID 和聊天关系；这些信息可能超出解析单个联系人的必要范围。风险发生在代理依照宽泛请求或自行选择该筛选方式时，但数据仍受当前用户身份的可见范围限制。用户可要求作者默认禁止 filter-only 枚举、限制返回字段，并在批量查询前确认范围与用途。
`--query` / `--queries` / `--user-ids` / bool filter 至少传一个。bool filter 显式传 `=false` 会报错——不传等于不过滤。查看另外 4 个位置
# filter-only 枚举:列出所有"聊过天的离职同事"(无关键词)lark-cli contact +search-user --has-chatted --left-organization```- ✅ 已知姓名 / 邮箱 / 「聊过的人」想找出 open_id- ✅ 已知一组 open_id 想批量校验或回填字段(`--user-ids`,最多 100,支持 `me`)- ✅ 按聊天关系 / 在职状态 / 租户边界 / 企业邮箱等维度筛选员工- ❌ 已知 open_id 想发消息 → 直接走 `lark-im`,不经过本命令| `localized_name` | string | 按 `--lang` / brand 选出的展示名 | 始终非空(兜底为 open_id) || `email` | string | 个人邮箱 | 可能为空 || `enterprise_email` | string | 企业邮箱 | 可能为空 || `is_activated` | bool | 是否已激活飞书账号(未激活也可投递消息,但用户可能看不到) | 可能 false || `is_cross_tenant` | bool | 是否跨租户用户(同公司=false,外部联系人=true) | — || `p2p_chat_id` | string | 与当前用户的 P2P 会话 ID(`oc_...`);空表示从未私聊过。可作为接受 `--chat-id` 的 IM 命令的输入 | 可能为空 || `has_chatted` | bool | `p2p_chat_id != ""` 的派生字段 | — || `department` | string | 部门路径,服务端可能用 `-` 拼层级,层级数不固定。**按可子串匹配的字符串处理** | 可能为空 || `signature` | string (optional) | 用户个性签名;空时字段不出现 | 可能不出现 || `chat_recency_hint` | string | 最近联系的提示文案,仅供展示 | 可能为空 |- **41050 / Permission denied** 受当前身份的可见范围限制(三条命令都可能遇到)。细节见 [`lark-shared`](../lark-shared/SKILL.md)。- **跨租户用户**(`is_cross_tenant=true`)多数业务字段为空字符串,这是飞书可见性规则,下游做空值兜底。- **ID 类型**:`+get-user` 可通过 `--user-id-type` 使用 `open_id`、`union_id` 或 `user_id`;`+search-user` 使用用户 open_id;`+search-bot` 不支持按 ID 查询,它按关键词搜索并返回机器人 open_id。