swesee Security

The macOS companion (Swesee.app and the headless SweseeService CLI fallback) and the shared wire-protocol package (swesee-core) are open source under MIT once the App Store build is submitted; until then, both repositories remain private during pre-submission. You will be able to verify every assertion below by reading the source.

• macOS service (Swesee.app + SweseeService CLI): github.com/rondesta/swesee-service — will be made public at App Store submission
• Wire-protocol package: github.com/rondesta/swesee-core — will be made public at App Store submission

Threat model

swesee is built for a single user pairing their own iPhone or iPad with their own Mac on a Wi-Fi network they trust — typically a home or office network. It is not a multi-tenant cloud service, and it does not attempt to defend against an attacker who already has physical access to the user's Mac or who has compromised the user's Apple account.

The active attacker we do defend against is another device on the same Wi-Fi network. We enforce three boundaries against that attacker, in code we ship today:

1. An unpaired device cannot get past the wire-level handshake (next section).
2. A paired device, once authenticated, sees only what the macOS file sandbox grants the Mac binary (file-exposure section).
3. Neither side reaches any remote server, so an attacker cannot pivot to a cloud surface to extract data later.

How we authenticate paired devices

Bonjour discovery alone is not authentication: anyone on your Wi-Fi can see that Swesee.app is running on your Mac and advertising the _swesee._tcp service. To use the service, a device must complete a pairing handshake first.

We enforce the pairing boundary on the Mac side, before any file or git request is honored:

• On a new connection, the macOS service starts in an unauthenticated state. Until a valid HandshakeRequest frame arrives, every other frame is dropped and the TCP connection is closed. (Enforced in MessageHandler.swift: if !authenticated { ... connection.cancel() }.)
• A new device must present a six-digit code shown in the Mac menu-bar popover. The code is one-time, time-limited, and consumed atomically by the PairingCodeManager; replay attempts fail.
• On a successful pairing, the Mac mints a 256-bit per-device token and stores it on disk at ~/.swesee/trusted-devices.json with file mode 0600 (owner-only). Future reconnects from that device present the token instead of the code; an attacker who didn't see the original handshake cannot recover the token from the wire.
• You can revoke a device at any time from the macOS menu-bar popover. Revocation deletes the device's token from the trust store; the next connect attempt from that device gets .invalidToken and must re-pair.

Wire protocol

• Discovery: the Mac advertises Bonjour service _swesee._tcp. We enforce that no other service ID is broadcast: NSBonjourServices in both Info.plist files declares only this single service, and the NWListener in ServiceServer.swift uses the same constant.
• Transport: plaintext TCP over your LAN. We do not currently enable TLS on the wire — both endpoints construct NWParameters(tls: nil, tcp: ...) explicitly. The pairing-handshake token (256-bit, indistinguishable from random) is the security boundary against an authenticated attacker, but a passive on-link attacker on the same Wi-Fi can observe file listings, file contents, and git diffs in clear text. This is acceptable for our threat model (trusted home/office Wi-Fi) but should not be misread as "TLS where available". TLS-over-Bonjour is tracked for a future release.
• No traffic to any remote server. We enforce this by writing no HTTP client code: URLSession and URLRequest do not appear anywhere in the iOS app, the macOS service, or the shared wire-protocol package. The only network code path uses Apple's Network framework, scoped to your LAN.

What Swesee.app exposes (read operations)

Once a device is paired, Swesee.app responds to read requests for:

• File tree listings (recursive on demand)
• File contents (text files and inline-rendered images)
• git status, git diff, git log, git show, and per-path commit history
• Folder size + breakdown summaries (recursive)
• Host info (disk, memory, uptime) for the Settings panel
• GitHub issue listings (via the user's own gh CLI authentication; no swesee-side credentials)

We enforce that git commands cannot escape the requested repository: every shell-out to git in GitCommandRunner.swift is prefixed with git -C <path>, so git itself constrains the working directory. Symlinks inside the workspace are followed at most once per real path (the walker tracks resolved paths to break cycles).

What Swesee.app exposes (write operations)

For full transparency: Swesee.app does ship a small set of write operations. They are:

• Rename a file or directory within its parent folder (uses FileManager.moveItem).
• Move a file or directory to the macOS Trash (uses FileManager.trashItem — recoverable from the Finder).
• git push for the currently-viewed repository.
• GitHub issue mutations (create, edit, close, reopen, comment) via the user's own gh CLI authentication.

All write operations require an authenticated pairing first — an unpaired device cannot reach them. The git push and issue mutations carry no swesee-side credentials; they shell out to the user's installed tools and inherit the user's existing GitHub authentication.

How the file sandbox limits access

The version of Swesee.app shipped on the Mac App Store runs inside Apple's app sandbox. We enforce this with the entitlements file (Swesee.entitlements):

• com.apple.security.app-sandbox = true
• com.apple.security.files.user-selected.read-only = true
• com.apple.security.files.bookmarks.app-scope = true
• com.apple.security.network.server + com.apple.security.network.client = true (for the Bonjour-discoverable TCP listener)

The files.user-selected.read-only entitlement means the kernel rejects file reads outside the workspace URL you granted the app via the "Change..." button (an NSOpenPanel). We persist that grant as a security-scoped bookmark so the picked folder keeps working across restarts without re-picking. The Mac App Store version of Swesee.app cannot read files outside the root you chose, even if a paired iOS device requests them — the macOS kernel enforces this independently of Swesee's own code.

What the directory walker hides by default

When Swesee.app walks your workspace, the file-tree walker (FileSystemWalker.swift) skips folder names that would either swamp the listing or expose data that's never useful to browse:

• .git — opaque git internals; the git operations in the previous section give you the data you actually want.
• node_modules, Pods — dependency caches with millions of files.
• .DS_Store — macOS Finder noise.
• Top-level home-folder directories that are never code-relevant when the workspace is rooted at $HOME: Library, Applications, Movies, Music, Pictures, Mobile Documents.

Hidden folders (dot-prefixed) other than .git are deliberately kept visible, so you can navigate into ~/.claude, ~/.config, ~/.aws, and so on. Build-output folders (.build, .swiftpm, DerivedData) survive too; the trade-off is a few extra rows inside a repo in exchange for the user being able to inspect build output.

Reporting security issues

Email security@swesee.com. We aim to acknowledge reports within five business days. There is no formal bug-bounty program at this time. A machine-readable contact record is published at /.well-known/security.txt per RFC 9116.

Verify for yourself

The repositories above (swesee-service and swesee-core) will be public at App Store submission. From that point, every byte the Mac service sends — the wire protocol, the pairing handshake, the path-pruning rules, the git command construction — is in code you can read. The iOS app's source remains closed (commercial product surface), but the Mac side, which is what touches your filesystem, is fully auditable.

Last reviewed: 2026-05-17