Account access and troubleshooting
3 minute read · Account usage
Use this guide when Vortex opens but a project, connection or agent action is unavailable. Vortex is free to use; ordinary account verification, encryption and the permissions of the services you connect still apply.
- Find which part needs attention
- Sign in and unlock the right account
- Check the project and connected resource
- Handle a failed or interrupted action
- Report the useful evidence
Find which part needs attention
| What you see | First check |
|---|---|
| Sign-in or email verification required | The selected Vortex account and the verification or recovery step shown. |
| Vault locked or a saved credential will not decrypt | Unlock with that account's existing Vault password or recovery flow. |
| Provider unavailable or usage exhausted | Settings → Agents & chat and the chosen provider's account/status message. |
| A project folder cannot be opened | Whether that checkout exists on this computer and its local folder binding is correct. |
| Another device is running this chat | The active device/run and whether that work has finished. |
| An external database, server or API rejects an action | That service's identity, connection settings and actual permissions. |
Sign in and unlock the right account
Use the account menu to confirm which account is active before opening saved work. Complete verification or two-factor authentication if requested. If you can sign in but cannot read an encrypted credential, continue with Vault unlock; logging in does not replace the key needed for decryption.
Do not create duplicate accounts or clear the profile to hide an error. Preserve your recovery material and local work while following account recovery and Vault recovery. Account changes should show that account's own work, not mix resources from another identity.
Check the project and connected resource
A synchronized project remembers its history, but each computer needs a real checkout folder. Bind the correct folder and verify the branch before starting an agent or app process. Read continuing on another computer when moving between machines.
For a database or server connection, check the intended host, database and user without copying its secret into chat. A valid password can still belong to a read-only database user or an account without repository access. Shared resources also keep their owner/editor/viewer permissions. Ask the resource owner for the access actually needed rather than switching to an unrelated account.
Handle a failed or interrupted action
Read the error and check whether any work completed before retrying. Sending another request, rerunning a script or reconnecting a terminal does not roll back a previous write. Open the captured result and relevant logs, then choose a bounded next step.
Keep pending drafts, unsynced edits and existing connection definitions while investigating. Never replace an unreadable master key, delete a checkout or remove a saved connection merely to dismiss a warning. Normal updates should be installed through the trusted download/update path while preserving the existing profile.
Report the useful evidence
Include your operating system, Vortex version, the selected module, the action and the exact sanitized message. Explain whether the problem also occurs in a new empty chat or only with one existing resource; do not delete the original to test that distinction.
A screenshot can help, but hide passwords, keys, tokens, personal records and recovery links. Support and bug reports provides a checklist. Using Vortex and its limits explains provider usage and technical cloud capacity separately from account access.