lark-cli probes the ~/.ssh directory at startup

[EN] lark-cli probes the ~/.ssh directory at startup, triggering security sandbox protection prompts

Summary

On Windows, every lark-cli invocation performs metadata-level probes against the user's C:\Users\<user>\.ssh directory. lark-cli has no SSH-related functionality, so this access is unexpected. On machines where security tooling (sandboxing / EDR / least-privilege wrappers) protects ~/.ssh as a sensitive path, this probe triggers a protection or approval prompt for every CLI call, which degrades the automation experience (agents/CI calling lark-cli repeatedly).

Environment

• lark-cli version: 1.0.95 (npm package @larksuite/cli, native Go binary)
  • binary build info: github.com/larksuite/cli v1.0.93, GOOS=windows GOARCH=amd64, CGO_ENABLED=0, built 2026-09-01
• OS: Windows 11 Pro 26100 (Windows 10/11, 64-bit)
• Invocation: lark-cli <any command> (e.g. lark-cli --version, lark-cli base +record-get ...)

Observed behavior (Process Monitor, filtered on Path contains .ssh)

14 events in ~1 second, all from lark-cli.exe, all targeting C:\Users\<user>\.ssh itself (never any file inside it):

CreateFile                        x4   Desired Access: Read Attributes
QueryNetworkOpenInformationFile   x3   (directory timestamps)
QueryDirectory                    x1   Filter: .ssh  (existence probe)
QueryInformationVolume            x1   (volume serial / label)
QueryAllInformationFile           x1   (directory attributes)
CloseFile                         x4

Key points:

• Zero bytes are read; no file inside .ssh is ever opened; no directory listing of its contents occurs (the only QueryDirectory filters by the name .ssh itself — an existence check).
• The probe happens on every invocation, before any command-specific work.

Static analysis

The binary's embedded Go build info shows the full dependency list. It contains no SSH-related library (no golang.org/x/crypto/ssh, no go-git), and the strings known_hosts, SSH_AUTH_SOCK, id_rsa, ssh-agent, ssh-keygen, ssh.exe do not appear at all. The string .ssh appears exactly once, in the constant pool adjacent to .aws, .npmrc, .netrc, .git-credentials — consistent with a hardcoded list of well-known credential/sensitive directories that the CLI stats at startup.

Expected behavior

Since lark-cli does not use SSH in any way, it should not touch ~/.ssh at all. Please remove (or make opt-in/off by default) the startup existence-check of sensitive directories such as ~/.ssh, or gate it behind a diagnostic command (e.g. lark-cli doctor) instead of running it unconditionally.

Impact

• Security sandboxes / least-privilege wrappers that protect ~/.ssh treat this as suspicious access and raise approval prompts or block the process.
• Breaks unattended usage: agents and CI pipelines calling lark-cli frequently get interrupted by prompts unrelated to the actual task.
• Users auditing lark-cli (rightfully) flag it as unexpected behavior: a messaging/docs CLI probing SSH key directories looks like credential discovery, even though no key material is read.

Notes

• rsa/ed25519 string hits in the binary come from Go's standard crypto/tls stack (HTTPS to the Lark Open API) and are expected; only the ~/.ssh directory probe is at issue here.
• Happy to provide the full Process Monitor XML log if needed.

---

[中文参考版] lark-cli 启动时探测 ~/.ssh 目录，触发安全沙箱保护提示

概述

在 Windows 上，lark-cli 每次调用都会对 C:\Users\<用户>\.ssh 目录做元数据级探测。lark-cli 没有任何 SSH 相关功能，这一访问并不必要。当本机安全软件（沙箱 / EDR / 最小权限封装）把 ~/.ssh 作为敏感路径保护时，每次调用 lark-cli 都会触发保护或审批提示，影响自动化场景（智能体、CI 高频调用 lark-cli）的体验。

复现

任意命令即可复现（如 lark-cli --version），用 Sysinternals Process Monitor 过滤 Path contains .ssh 可观察到 14 条事件：4 次 CreateFile（Desired Access 仅 Read Attributes）、3 次时间戳查询、1 次 QueryDirectory（过滤条件为 .ssh 本身的存在性探测）、1 次卷信息查询等，全部针对 .ssh 目录本身，未打开其中任何文件、零字节读取。

静态分析

二进制内嵌 Go 依赖清单中无任何 SSH 库；.ssh 字符串仅出现 1 次，与 .aws、.npmrc、.netrc、.git-credentials 同属一组常量，推测为启动时对知名敏感/凭据目录的硬编码存在性检查。

期望行为

lark-cli 不使用 SSH，启动时不应访问 ~/.ssh。建议移除或默认关闭该探测；如确有需要，应收敛到 lark-cli doctor 等显式诊断命令中。

影响

• 沙箱类安全策略会对该访问报警/拦截，自动化与无人值守场景被打断；
• 用户安全审计时会将"文档/消息 CLI 探测 SSH 密钥目录"视为可疑行为，损害信任。

Start by locating the Go startup code that checks the hardcoded sensitive-path list, searching for .ssh alongside .aws, .npmrc, .netrc, and .git-credentials. Reproduce lark-cli --version on Windows with Process Monitor, then verify that startup no longer probes ~/.ssh or that the check is restricted to an explicit diagnostic command.