OrgX Wizard helps connect the AI clients you already use to an OrgX workspace. Its job is to make setup inspectable: show what it will change, apply the selected configuration, and report what still prevents the connection from working.
This April 2026 post explains the setup problem. For commands, supported clients, and authentication details that change over time, use the current setup guide and Wizard package. Configuration being present is only the first check.
What setup needs to establish
| Check | Inspect |
|---|---|
| Configuration | The client loaded the intended server. |
| Authentication | The server accepted this client’s session. |
| Workspace | A retrieved record belongs to the workspace you intended. |
Passing one check does not establish the others. A healthy server can still reject your session.
This is why one generic configuration snippet is often insufficient. Clients store settings in different places and expose different connection flows. Installed plugins may own their own skills or tools. Writing another copy can create confusion rather than capability.
Wizard detects supported local clients and offers the OrgX configuration and companion components appropriate to them. Review the selected scope before accepting setup, especially when it offers plugins, rules, or hooks. The installed version and client determine which choices are available.
Follow one connection through
Suppose, as an illustrative example, you use one client for implementation and another for review. You want both to inspect the same prioritization decision.
- Run setup and choose the clients you intend to configure.
- Review its proposed changes and complete the relevant authentication flow.
- Select the intended OrgX workspace. Do not infer the workspace from the directory name alone.
- Open the client and inspect its authenticated OrgX tool list.
- Ask it to retrieve an existing decision and open the returned source link.
npx @useorgx/wizard@latest setup
npx @useorgx/wizard@latest doctorThe useful result is a record you recognize from the right workspace. If the client cannot find it, distinguish missing data from an unavailable connection before changing the configuration again.
What doctor can tell you
The diagnostic command checks the local setup and the connectivity available to it. Its output can identify configuration, authentication, workspace, or local integration problems that need repair.
Its authority has a boundary: a command-line API-key check does not prove that a separate client has completed its own OAuth connection or loaded the same tool profile. Likewise, a successfully written hook configuration does not establish that the host has trusted or executed that hook.
Read the failing check and use the current troubleshooting instructions. In the client, confirm the workspace and retrieve one known record. That second check tests the path you actually intend to use.
Keep setup reversible
Configuration is part of a developer's working environment. A useful installer should preserve unrelated settings, identify what it owns, and provide a supported removal path. The Wizard's source describes its managed configuration and uninstall behavior; inspect those boundaries for the version you install.
Before rerunning setup, compare its managed entries with the problem reported by doctor. Keep unrelated hooks and settings intact. Use the supported uninstall command to remove the component you selected, then check the client's configuration rather than deleting the whole file.
Avoid treating installation as permission to capture everything. Companion packages, user-selected capture options, and client hooks have different responsibilities. Some plugins deliberately provide a narrow status or read-only surface. A successful plugin install does not imply automatic transcript capture or full write capability.
The same distinction applies to continuity. Setup creates a route into shared records. It cannot make an unsaved decision appear in another client, and cross-client recovery remains partial beta support.
After connecting, try a small read-only prompt: ask OrgX to confirm the workspace and retrieve one recent decision with its source. Check that record before testing a second client. The first useful setup outcome is evidence that this connection works for your work, with its remaining limits stated plainly.