How do I troubleshoot Cortex access and command failures?

Start with the exact error and the Account used by the failing interface. An empty result, missing permission, expired connection, and unsupported command need different fixes. Before repeating a write after a lost response, read the affected resource to find out whether the first request succeeded.

A list is empty or a Module is missing

With the CLI, confirm your Account and search the active knowledge you can access:

socra account status
socra cortex module search --query "your topic"
socra cortex module list

Follow any returned pagination cursor before treating a list as complete. A new Account may have no Modules. A Module in another Account, or one you lack permission to discover, will not appear. Signing in to the website does not change a separate agent's stored authorization.

Check archived Modules if you expect retired knowledge:

socra cortex module list --archived

An archived Module cannot be Flashed. Restore it only when its knowledge should govern work again and you have authority to do so. Issue access alone does not necessarily provide access to its Module's content.

A command is unknown or its output looks wrong

Read the failing command's help, for example:

socra cortex module list --help

Check that the required CLI plugin is installed. socra update updates the host and installed plugins; it does not grant Module access or prove that an empty result is a defect. After a successful update, retry the read that failed. Keep the exact command and error if the problem remains.

Authentication or permission fails

A 401 response means the request did not supply an acceptable authorization. Reconnect the failing agent integration, or sign in again with the CLI, and select the intended Account. Wait for that interface to confirm completion, then make a read-only Cortex call.

A 403 response can indicate missing permission or a service-admission restriction. Read the returned error and confirm the principal and operation before changing access or reconnecting. If permission is missing, ask the Module owner or an authorized administrator for the specific access needed. Missing Module reads may appear as not found to avoid disclosing knowledge. Do not try another identity to bypass the boundary.

A Flash or write is refused

Flash includes transitive Dependencies, so extra Modules are expected. For an archived Dependency or a cycle error, inspect the named Module and have its owner repair the knowledge graph. A write also needs appropriate edit permission and valid content or Dependencies. Host approval does not grant missing Cortex permissions.

An Issue is absent from the inbox

Replace ISSUE_ID with the Issue's ID and inspect the record and timeline:

socra cortex issue get ISSUE_ID
socra cortex issue timeline ISSUE_ID

Check assignment, status, release timing, Dependencies, and your access. The inbox is a ready-work view, not a list of every Issue. Do not mark unfinished prerequisites done merely to make another Issue appear.

Reopening a recorded Flash currently rebuilds the target's current knowledge and Dependencies. Its content can differ from the original result, and it can fail after a Module is archived. Preserve the Flash ID and exact error when reporting a failure. Use Module version history to inspect recorded versions. Restoring retired knowledge merely to read an old Flash changes active knowledge.