Clawdline v2.1.2

Editorial introduction

Confirms application-level encryption, browser crypto and pairing. Residual risks include endpoint compromise, local key files and production/revocation acceptance gaps.

Reading scope: Go/browser crypto, replay, endpoints/transmission, key storage, HTTP gate, installer and runtime-status documentation.

The v2.1.2 release URL also supplied to the reviewer

This response concerns pinned source 239adc8ad and v2.1.2. That source’s README still selects v2.1.1; the later main branch selects v2.1.2. This is not evidence that the v2.1.2 release is missing. Untraced authentication or key-rotation wiring is not proof that those mechanisms are absent.

Download the complete original English text · SHA-256 13d6b1076385855742a4a3f875522d354497918b4cfba0608a5fbb95029b543c

Complete original response

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

1. 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.

2. Remote operation can lead to code execution. The implementation separates Cloud connectivity from a cloud_commands switch. 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

3. 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

4. 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.