Team Onboarding | Ghostable CLI 3.x | Ghostable Menu Team Onboarding Join from the new device ------------------------ After cloning the repository, the new team member creates a device identity: New team member Copy ``` $ ghostable access join --name "Alex MacBook" ``` This writes a self-signed public device record under `.ghostable/devices/`. The signing and encryption private keys stay in the platform secret store on that device. Request access -------------- The new device requests the least-privileged role it needs: Request development access Copy ``` $ ghostable access requests create --env default --role writer --reason "Joining application team" $ git add .ghostable && git commit -m "Request Ghostable access for Alex" ``` Open a pull request containing the device and request records. An owner or grantor can inspect the device label, public-key fingerprints, requested scope, and reason before approving it. Approve the request ------------------- From a checkout containing the request, an authorized device lists and approves it: Owner or grantor Copy ``` $ ghostable access requests list $ ghostable access requests approve --request-id --reason "Approved for application development" $ git add .ghostable && git commit -m "Grant Alex Ghostable access" ``` Approval creates or updates signed policy and per-device environment grants. For a direct grant, an owner or grantor may use `ghostable access share --device-id --env default --role writer` instead. The simplest review uses one pull request: the requester opens it, an authorized approver checks out or fetches that branch, adds the signed approval commit, and pushes it back to the same pull request. If branch permissions prevent that push, place the approval commit in a follow-up pull request and merge both before the requester attempts to decrypt values. Do not treat a request-only commit as completed access. Git review and Ghostable authority are separate Ghostable verifies that the approving device is an owner or an environment grantor. It does not require that requester and approver are different people; use branch protection or repository review rules when a separate human approval is required. Verify access ------------- Once the approval commit is merged, the new team member pulls it and verifies access: Verify the grant Copy ``` $ git pull $ ghostable access status $ ghostable env pull --env default --file .env ``` A production-like pull also requires the local operating system's user-presence confirmation. Roles ----- `reader` Decrypt and read values in the environment. `writer` Includes reader access and may create, change, promote, or delete values. `grantor` Includes reader access and may grant or review access for the environment; it does not imply write access. `owner` Project-wide ownership with read, write, grant, and ownership authority. Grant the smallest useful role Most application developers need `writer` in development environments and, at most, `reader` in production. Reserve `owner` for the small set of people responsible for project policy and recovery. Offboarding ----------- For offboarding or a lost device, revoke the identity from every environment and commit all signed changes: Remove a device Copy ``` $ ghostable access revoke --device-id --env all $ git add .ghostable && git commit -m "Revoke retired Ghostable device" ``` Revocation permanently marks that device identity as revoked and automatically rotates each affected environment key. The device cannot be granted access again; it must rejoin with a new identity. Although `--env` can name one environment, it controls which grants and environment keys are changed—not whether the identity is globally revoked—so use `all` for offboarding and compromise response. Rotation blocks the revoked identity from decrypting future Ghostable values. It cannot erase plaintext the device already read or secrets recoverable from older Git history. If compromise is possible, also rotate the underlying database password, API key, or provider credential at its issuer. A revoked public device record can be deleted later with `ghostable access delete`. Ghostable prevents revoking or removing the last owner. On this page [ ![Ghostable](https://ghostable.dev/images/logo-dark.svg) ![Ghostable](https://ghostable.dev/images/logo-light.svg) ](https://ghostable.dev) CLI 3.x [ CLI 3.x ](https://ghostable.dev/docs/3.x) [ Desktop ](https://ghostable.dev/docs/desktop) CLI 3.x introduction Documentation local first no login encrypted repository plaintext hosted service Installation Documentation brew homebrew npm npx linux windows PATH version update Start a new project Getting Started setup seed dotenv owner initialize Adopt an existing project Getting Started existing env import authoritative source adopt Onboard a team member Getting Started join request approve roles offboarding pull request Repository and storage Core Concepts .ghostable git conflict merge worktree private identity metadata Environments Core Concepts protected production preview staging push sync pull replace run mask-output Variables and promotions Core Concepts var promote copy context annotation key Access and devices Core Concepts identity reader writer grantor owner revoke rotate leave delete Daily development workflow Workflows pull diff validate review clean daily Review and secret scanning Workflows scan sarif github suppress secrets drift Hygiene and rotation Workflows rotation stale unused suppression environment key Automation credentials Automation & CI GHOSTABLE\_CI\_TOKEN ci deploy credential powershell revoke replace Continuous integration Automation & CI GitHub Actions fork pull request JSON stdout stderr exit codes mask-output Deployments Automation & CI Forge Vapor Cloud provider CLI dry-run preserve remote keys temporary files Validation Reference schema required nullable regex min max different\_from Command reference Reference --help --json NO\_COLOR flags aliases exit code automation Configuration Reference ghostable.yaml activity mode auditEnvironments scan ignores deployTarget dotenv syntax Security Reference cryptography XChaCha20 Poly1305 HKDF user presence threat model Backups & Offline Reference recovery offline restore clone key identity Agent integration Reference AGENTS.md capabilities allowlist coding agent Troubleshooting Reference no project found revoked identity stale policy user presence invalid CI token provider CLI git conflict diagnostics Ghostable Desktop overview Desktop Installation Desktop Projects and setup Desktop Interface tour Desktop Environments and variables Desktop Local environment files Desktop Validation and review Desktop Activity Desktop Access and automation Desktop Project settings Desktop Application settings Desktop Licensing and updates Desktop Security and storage Desktop Troubleshooting Desktop No results found