Clawdline v2.1.3

Editorial introduction

Recognizes Go/browser encryption, pairing, network defaults and access controls. Residual concerns include endpoint compromise, file keys and production revocation guarantees; binaries and private Cloud were not verified.

Reading scope: Pinned raw Go/browser crypto, pairing, settings/relay, file keys, installer, HTTP/auth and rotation/data-flow documentation; partial listing failures and no execution.

This is a limited public-web review of pinned source fcc905914 and the v2.1.3 release page, not a security certificate. No installation, exploit testing, binary verification or inspection of private production Cloud was performed. Some public directory/asset reads failed; Claude web fetches may provide summaries. An unreviewed mechanism or inference is not an established vulnerability.

The pinned README still selected v2.1.2 when reviewed; that observation is preserved. Later main commit 9e5a7ad updated it to v2.1.3. This rerun did not inspect the Swift native pairing bridge and cannot establish that concerns in the separate 2.1.1 report are resolved. The previous v2.1.2 response remains available for comparison.

Method: only public source/release URLs and the question were supplied, with repository context disabled. Visible tool records show network reads only. Each initial Codex job lacked network tools and was excluded as a technical failure; each was retried once. Valid outputs are preserved, including their status footers; this does not claim that all built-in instructions were removed. Full methodology.

Download the complete original English text · SHA-256 f93cb86ce57034cdc80d9d70d98f139cb7055bfe2bf8d55b85dbaf887d8f70c5

Complete original response

Bottom line

Yes—there is meaningful security risk, principally because Clawdline is a remote-control tool with access to sensitive developer data. The accessible code implements real encryption, not merely HTTPS with an “end-to-end encrypted” label. However, I cannot certify the v2.1.3 download or the production Cloud service as safe.

My assessment: potentially reasonable for a personal development machine with careful configuration; insufficiently verified here for an unrestricted installation on a machine holding production credentials or confidential work.

I reviewed security-relevant source at commit fcc9059142485514d54683adb769710abb96e1ab, not just the README.

Encryption and transmission

What I could verify in code

• Content encryption: Go’s Seal encrypts payloads with AES-256-GCM, using fresh 12-byte nonces from crypto/rand by default and a 16-byte authentication tag.
• Sender authentication: Envelopes receive Ed25519 signatures covering ciphertext and routing fields. Open verifies the signature against the sender’s pinned public key before decrypting. The sender identifier itself is not signed; its binding depends on that pinned-key lookup.
• Browser implementation: The browser likewise uses WebCrypto AES-GCM and Ed25519, verifies before decrypting, and generates random nonces. These are substantive implementations of endpoint encryption. Go encryption source, browser encryption source

Pairing uses a random 32-byte invitation secret. The code puts that secret in a URL fragment and computes its SHA-256 hash for the service. Invitation offers are AES-GCM encrypted; the handover mechanism uses X25519 and HKDF-derived keys to transfer content-key material. This provides a credible cryptographic pairing design, but does not independently prove the private service enforces one-time claims correctly. Pairing source

Network defaults are wss://relay.clawdline.com/v1/connect and https://api.clawdline.com. Cloud and remote-command permission default to false; direct connections default to enabled when Cloud is used. The documented WebRTC path carries the same encrypted envelopes for supported reads, with relay fallback. I inspected the relay integration, but did not fully audit the WebRTC implementation. Settings source, relay integration, wire specification

Important residual risks

1. A trusted endpoint can become a powerful attack endpoint

Clawdline accesses conversations, project files and terminals. An authorized operating browser can send instructions and use terminal functionality. Consequently, compromising that browser or machine could expose secrets or enable commands under your account—not merely leak chat history. Read-only pairing reduces effects, but still permits sensitive reads. Repository overview, grant boundaries

2. Encryption does not eliminate trust in the hosted web application

Browser keys are stored as non-extractable CryptoKeys in IndexedDB. My security inference: non-extractable does not stop malicious same-origin JavaScript from using those keys or reading decrypted content. A compromised hosted frontend or an XSS vulnerability could therefore undermine confidentiality despite sound encryption. I did not establish such a vulnerability, but the trust boundary remains. Browser key storage and decryption

3. Machine secrets are files, not hardware-protected keys

The daemon stores signing seeds and content keys as base64-encoded files, protected with 0700 directory and 0600 file permissions. This is not encryption at rest. Same-user malware, root access or exposed backups could obtain them. Key-store source

4. Cloud still learns metadata; Cloud-off is not necessarily offline

Routing identifiers, timestamps, message sizes and traffic patterns are outside payload encryption. The repository’s outbound inventory also lists update/build checks independently of Cloud, and STUN services for direct connectivity. That inventory explicitly describes an earlier revision, so I treat it as supporting documentation—not a complete verified egress inventory for this commit. Data-flow inventory

5. Revocation is not retroactive confidentiality

Revocation cannot erase plaintext or keys already copied by a device. The repository contains content-key rotation integration, but its accompanying record explicitly says acceptance remains pending. I cannot verify production future-content revocation guarantees from this review. Rotation implementation record

Installation protections and limitations

The installer contains a pinned Ed25519 release-verification key and verification machinery; its download helper enforces HTTPS except explicit loopback mirrors. Those protections reduce download-substitution risk, but still require trusting the installer, release signer and build pipeline. The release page claims a signed/notarized DMG; I did not independently validate that signature, notarization, manifest, or binary-to-source correspondence. Installer source, v2.1.3 release

Local HTTP code also includes authentication, same-origin checks, capability checks and pairing rate limits—positive safeguards, not proof every route is secure. HTTP gate, authorization source

Recommendation

Start local-only, without production secrets; enable Cloud only if needed, explicitly choose read-only pairing where possible, and pair only trusted browser profiles. Verify the exact release before installing.

Reading limitations: This was a targeted static review through public network access. Repository directory/API listings were partly inaccessible, although numerous commit-pinned raw files were readable. I did not read every source file, run tests, install binaries, capture traffic, or audit dependencies comprehensively. The private Cloud backend, deployed frontend, retention practices and production configuration were unavailable; the repository itself acknowledges that boundary. Accordingly, I found credible security mechanisms, not sufficient evidence for an unconditional “safe to install.” Public/private boundary

Fixed but not yet released (awaiting review): Nothing.