Skip to main content

​
Why This Exists

Ghostable keeps a strict zero-knowledge model: environment keys are never decrypted server-side. When a user links a new device (or gains access to an environment), that device cannot decrypt until an authorized teammate re-shares the environment key envelope. v2 now surfaces this as an explicit, auditable workflow instead of a silent failure.

​
Recipient Experience

When your device is missing key access, Ghostable returns a machine-readable ENV_KEY_RESHARE_REQUIRED state and shows a pending access message in clients.
  • CLI: env pull, env diff, and var pull display waiting guidance.
  • Desktop: environment variables show a dedicated Key Access Pending state.
  • Web: you can see pending request rows in the organization key re-share queue.

​
Actor Experience (Who Can Fulfill)

Only users who can manageSettings on the target environment can fulfill requests.
  • Desktop: fulfill from the organization key re-share queue (one click).
  • CLI fallback:
ghostable env reshare pending
ghostable env reshare fulfill <request-id>
ghostable env reshare fulfill <request-id> is safe for email and runbooks because it requires only the request id.

​
Troubleshooting

If a request is visible but cannot be fulfilled from your current machine:
  1. The account may have permissions but this device lacks local key material.
  2. Use another authorized device that already has the environment key.
  3. Run ghostable env reshare fulfill <request-id> from that device.
If you are a recipient-only user, contact an environment manager in your organization.

​
Audit Trail

Lifecycle events are recorded for each request:
  • environment_key_reshare_requested
  • environment_key_reshare_notified
  • environment_key_reshare_completed
  • environment_key_reshare_cancelled
  • environment_key_reshare_superseded
These events appear in activity/history feeds and include request metadata (target user/device, environment, key version, source, and resolver when applicable).