Security & Storage

Ghostable Desktop is a local interface to the CLI engine. Project values are encrypted before repository storage and decrypted only on a device with the required identity and environment access. Ghostable does not operate a hosted service that receives those plaintext project secrets.

That statement does not make every local workflow zero-risk. The operating system, clipboard, editor, generated files, terminal processes, CI runners, deployment providers, backups, and anyone controlling an authorized device remain separate trust boundaries.

Read the CLI Security reference for cryptographic primitives, threat-model scope, audit status, and repository-level recovery constraints.

The .ghostable/ directory contains the project manifest, encrypted environment values, public device records, wrapped environment keys, signed policy and activity, validation schema, and other engine state. It is designed to be committed and reviewed.

Encrypted does not mean disposable. Back up repository history and preserve at least one authorized owner identity. Encrypted values cannot be recovered from Git alone when every valid private identity and usable key envelope is lost.

Project device private keys are stored outside the repository using the CLI's platform identity store. On macOS this normally uses Keychain; development or explicitly configured environments can use a protected file-backed keystore.

A project identity is different from the Desktop activation token. Backing up or releasing one does not manage the other.

• Launcher groups, project names, and local repository paths are stored as local application organization state.
• General and appearance preferences are stored in the Desktop application data directory.
• The protected license activation token is stored in macOS Keychain; signed entitlement metadata and validation status are cached in application data.
• Project plaintext is not intentionally copied into launcher metadata or license state.

macOS backups may include some application metadata. Apply the same device encryption and backup controls you use for source repositories and developer credentials.

Core project management is local and repository-backed. Desktop makes network requests for license activation and validation, activation release, and update checks or downloads. Links such as purchase, documentation, privacy, or support open the configured Ghostable website in the system browser.

Licensing requests do not need project environment values or repository contents. Deployment operations are separate: when you intentionally deploy, the destination provider or process receives the plaintext values necessary to run the application.

• Revealing or editing a value exposes it to the current renderer, display, and operating-system process memory.
• Copying a value exposes it to the clipboard and any clipboard-history utility.
• Pulling a local file writes plaintext to disk.
• Opening a file or repository in an IDE extends trust to that editor and its plugins.
• Running or deploying with an environment extends trust to the child process, CI runner, and provider.

Use full-disk encryption, a locked screen, trusted editor extensions, ignored local files, minimal project roles, scoped automation credentials, and credential rotation after suspected exposure.

Desktop project and settings windows run with renderer sandboxing, context isolation, and Node integration disabled. A narrow preload API exposes approved operations, and the main process validates window roles, project scope, command allowlists, and file paths before invoking the CLI.

These controls reduce renderer-to-system risk but do not replace operating-system patching, signed updates, dependency review, or careful handling of untrusted repositories.