中文導讀（編輯整理）
確認應用層加密、瀏覽器密碼學與配對；剩餘風險包括端點入侵、本機金鑰檔及正式部署／撤銷驗收缺口。
實際閱讀範圍：Go／瀏覽器密碼學、重播、端點／傳輸、金鑰儲存、HTTP 防護、安裝及 runtime 狀態文件。
這份回覆針對固定來源 239adc8ad 與 v2.1.2。該來源的 README 仍寫 v2.1.1，後來主線已改為 v2.1.2；這不代表 v2.1.2 發行檔缺失。閱讀者未追蹤的認證／換鑰接線，不等於已證實該機制不存在。
下載完整英文原文 · SHA-256 13d6b1076385855742a4a3f875522d354497918b4cfba0608a5fbb95029b543c
完整英文原始回覆（未翻譯）
Yes—there is meaningful security risk, because Clawdline can expose sensitive development conversations and provide remote control of your machine. The code I inspected includes substantive encryption and access controls, but I would not describe v2.1.2 as independently verified safe.
I reviewed security-related source at 239adc8ad4020f31509bff017bd4e5a3ff913197, which the v2.1.2 release page identifies as its commit. This was a targeted static review through GitHub; I did not execute the application, capture traffic, audit every dependency, or verify the downloaded binaries against a source build.
What the encryption code actually does
- Content encryption: The Go implementation encrypts payloads using AES-256-GCM, with fresh random 12-byte nonces and authentication tags. It then signs the envelope using a separate Ed25519 device key. Incoming envelopes must verify against a known sender key before decryption. This is application-level encryption, beyond HTTPS alone. Encryption implementation
- Browser implementation: The JavaScript uses WebCrypto for AES-GCM and Ed25519, verifies signatures before decrypting, and stores pairing CryptoKeys as non-extractable keys in IndexedDB. Browser cryptography
- Pairing: The machine-side code uses ephemeral X25519 agreement and HKDF-SHA256 derivation bound to the pairing identifiers, nonces, and protocol phase. It rejects invalid or all-zero shared secrets. Pairing transfers the content key to the authorized browser. Pairing implementation
- Replay protection: A bounded per-sender sequence window rejects duplicate and sufficiently old sequence numbers. That primitive exists; its presence alone does not prove every execution path is replay-safe across restarts. Replay implementation
I did not identify an obvious cryptographic break in these inspected primitives.
How data leaves the machine
Cloud is disabled by default. Its configured production destinations are api.clawdline.com over HTTPS and relay.clawdline.com over WSS. Configuration validation rejects unencrypted remote endpoints, while permitting loopback HTTP/WS for local use. The relay connection sends its authentication token in an Authorization header. Endpoint settings, transport code
With Cloud enabled, session snapshots are published automatically; conversations, files, and attachments can be requested from the machine. The documented direct WebRTC path carries the same encrypted envelopes for supported reads, with relay fallback. Routing identifiers, timing, and traffic sizes remain visible outside the encrypted payload. Cloud disabled also does not mean zero network traffic: update checks can still contact external endpoints. Data-flow documentation, wire specification
The main remaining risks
-
A trusted browser becomes a sensitive endpoint. Encryption protects the relay path, but the browser must decrypt content. My inference from this architecture is that compromised hosted JavaScript, an XSS vulnerability, or a compromised browser could read decrypted content and use available authority. Non-extractable keys prevent ordinary key export; they do not prevent authorized same-origin code from using those keys.
-
Remote operation can lead to code execution. The implementation separates Cloud connectivity from a
cloud_commandsswitch. Local HTTP routes also enforce authentication, Host checks, origin checks for changes, and JSON body requirements. These are useful defenses, but granting terminal or agent control still grants consequential authority over your user account. Cloud switch implementation, HTTP security gate -
Machine keys are ordinary files. The Go key store uses base64-encoded secrets with owner-only permissions, atomic writes, and symlink defenses—not an OS Keychain or hardware-backed store. Malware running as your user, root access, or an exposed backup could compromise them. Key storage implementation
-
Installation still requires publisher trust. The installer verifies an Ed25519-signed manifest using pinned public keys, then checks the archive’s signed size and SHA-256 before extraction and execution. That protects against unauthorized artifact substitution, but cannot establish that publisher-signed code is harmless or that binaries reproducibly match this commit. Installer
What I could not verify
The repository explicitly excludes the production account backend, relay deployment, retention policies, and operational configuration. I therefore cannot verify production ciphertext retention, logging, deployed browser/source equivalence, or service-side enforcement. Public/private boundary
I also cannot certify complete future-content revocation: rotation code exists, but the accompanying runtime document explicitly leaves deployment and acceptance qualifications. Revocation cannot erase content already read. Rotation implementation status
My recommendation: local use with Cloud disabled is the lower-exposure choice. Enabling Cloud—especially remote commands—requires trusting the publisher, hosted browser application, paired devices, and your local account security. For confidential production credentials or regulated repositories, this review leaves too many deployment and binary-verification gaps to give an unconditional installation approval.
Fixed but not yet released (awaiting review): Nothing.