> ## Documentation Index > Fetch the complete documentation index at: https://docs.ghostable.dev/llms.txt > Use this file to discover all available pages before exploring further. # Key Re-Sharing > How Ghostable handles pending access when a new device or newly authorized actor still needs environment keys. Key re-sharing exists because new devices do not automatically inherit environment keys. ## Why It Exists Ghostable never decrypts environment keys server-side. When a user links a new device or gains new access to an environment, that identity may still need an authorized actor to re-share the existing environment key envelope. ## Recipient Experience When an identity is waiting on key access, Ghostable surfaces that state instead of failing silently. * **Desktop** shows a dedicated **Key Access Pending** experience in the environment window. * **CLI** shows pending guidance during encrypted workflows and exposes `ghostable env reshare` commands for recovery. * Promotion approval workflows in both clients can also trigger key-share recovery requirements before approval can complete. ## Who Can Fulfill a Request Only an actor who already has the necessary local key material and permission to manage the target environment can fulfill the request. ```bash theme={null} ghostable env reshare pending ghostable env reshare fulfill ``` ## If Fulfillment Still Fails * Use another authorized device that already holds the environment key. * Confirm the actor has environment-manage permissions. * If you are recipient-only, ask an environment manager in your organization to complete the request. ## Continue with Your Client Use the desktop troubleshooting flow when a Mac is linked but still waiting on access. Use the CLI device workflow when you need command-line recovery or fulfillment. Continue with promotion request create/review commands after key access is restored.