Common Fixes

Troubleshooting

Triage sign-in, setup, workspace creation, launch, logs, update, and billing-readiness issues from the Console workspace surfaces.

Customer adminsCustomer membersPlatform operators

Last updated June 18, 2026

Most workspace problems show their cause right in Console: a status pill, a blocker message, or the build and runtime logs. This guide walks the triage order — read the signal first, then take the matching action — and points you to the dialogs that carry the detail you will need when you escalate.

If you are reporting a Console workspace problem, start with the workspace Support dialog and the Logs view described below before you open a support case. They give you the exact status, build id, and agent readiness to include in the handoff.

Read the workspace status first

Open My Workspaces from the left navigation. Each row shows a status pill — Running, Stopped, Dormant, an active build, or an attention state such as Unhealthy. The header above the grid also surfaces how many workspaces need attention in the current view, so you can spot trouble before you scroll.

Each row carries inline actions on the right: start, stop, the Connect menu, Logs, and the overflow menu (Open workspace actions) with update, edit schedule, and delete. Which actions are enabled depends on the workspace state and your role. Use the status pill to choose the right next section below.

For the full meaning of each state and action, see Manage workspaces.

Open the Support dialog for a workspace

The Support dialog is the primary triage surface for a single workspace. It gathers health checks, runtime agent readiness, storage and Shared Drive posture, managed-access references, and recent usage in one place.

1. Find the workspace in My Workspaces.
2. Open the row’s overflow menu (Open workspace actions).
3. Choose Support.
4. Review the Health checks, Runtime agents, Storage, and Workspace integrations sections.
5. Use Runtime logs or Build logs from the dialog to open the matching log stream.

The Support dialog is available to platform operators and customer admins. If you are a customer member and do not see it, ask a customer admin to open it for the affected workspace. Support details are scoped: only people with access to a workspace can see them, and managed-access references stay protected — no secret values are shown.

When you escalate, include the workspace name, the visible health signal, and the agent-ready count (for example 1 / 1 ready). Do not include session tokens, cookies, or private prompts.

Read workspace logs

Logs are the fastest way to see why a workspace failed to start, stalled during provisioning, or behaved unexpectedly after launch.

1. Open the Logs action on the workspace row, or use Runtime logs / Build logs from the Support dialog.
2. While a workspace is provisioning, Console shows the Build log. It switches to the main Agent tail runtime stream as soon as it is available.
3. Use Refresh now to reload, and Download logs to save the current stream as text.

The footer confirms what is being tailed (for example, “Live tailing main agent logs for your workspace”). When you attach logs to a support case, download the text rather than pasting screenshots, and do not include tokens or cookies.

Create Workspace is blocked

The Create page shows the blocker before it lets you launch. Read it, resolve it, and only then retry. Common blockers:

Customer members should escalate billing and setup blockers to a customer admin. For target, alias, or provisioning blockers, escalate to ISM support. See Create the first workspace and Catalog and readiness for the upstream setup that clears these.

Create fails after provisioning starts

If a build starts and then fails, do not manually delete storage. Open the Logs view in Build mode to read the failure, then ask a customer admin or operator to decide whether to retry, cancel, stop, or delete through Console. Manual runtime cleanup is an operator fallback, not the normal customer path.

A build is stuck and blocks other actions

Start, Stop, Update, and Delete cannot run while a build is active. If a workspace is stuck building, cancel the active build so another action can run.

1. Open the workspace row’s overflow menu.
2. Choose Cancel build.
3. In the Cancel active build dialog, confirm with Cancel build, or keep it running with Keep build running.

The dialog names the active build so you can confirm you are cancelling the right one. After it cancels, the row’s other actions become available again.

Update review shows extra parameters

When you update a workspace, the active template usually preserves your saved parameters. If it cannot, Console opens an update review so you can confirm the proposed values before the build starts.

1. From the row’s overflow menu, choose Update.
2. If a review is needed, Console shows Review parameters with the adjustable values and the Update reasons.
3. Confirm the values, then choose Run update. Console validates server-side before starting the build.
4. Use Close update review to back out without starting an update.

Update can refresh saved workspace credentials during the build without exposing any secret values. After Run update, the status updates automatically — open Logs to watch the build.

A workspace went dormant

Workspaces can be marked dormant by the customer account’s dormancy policy after a period of inactivity. A dormant workspace shows a Dormant pill and its row offers an activate action. Starting it brings it back.

Dormancy and cleanup policy itself — mark-dormant and delete-dormant windows — is managed by platform operators and lives under the customer plan. Customer admins and members do not apply dormancy policy; if a workspace was cleaned up unexpectedly, escalate to ISM support with the workspace name and the date it disappeared.

Workspace launch opens the wrong place

Use the row’s Connect menu to launch. Browser opens the in-browser editor through the public workspace URL, VS Code Desktop and JetBrains Gateway use editor deep links, and Logs shows the Console-side startup stream. Windows workspaces add a Remote Desktop option through a private tunnel.

If a launch action opens an internal service address or a browser-unreachable location, report it with the workspace name, the launch option you chose (Browser, VS Code Desktop, JetBrains Gateway, or Remote Desktop), and the visible URL host. Do not include session tokens or cookies.

Archibot tooling looks stale in a running workspace

Running workspaces keep the Archibot tooling and editor extensions from the image they started with. If a workspace is missing a recently announced Archibot behavior, editor change, or tooling update, run the supported Update path (above) or create a fresh workspace.

For support, include the workspace name and which client is affected (Browser, VS Code Desktop, or JetBrains Gateway). Do not include session logs, cookies, tokens, or private prompts. See Workspace Archibot and Shared Drive for what the in-workspace assistant can reach.

Archibot cannot use workspace tools

Tool use depends on the workspace profile, connected services, and available credentials. If Archibot answers without using tools when tools should be available, retry with a direct request such as “search the workspace for…” or “run a SQL count for…”, and include the visible request or session id if you escalate.

If OneDrive is involved, confirm the connection in Console before retrying — OneDrive access is owned by the workspace user, and the Support dialog notes when a reconnect is needed. If Shared Drive is involved, confirm the drive is visible and that your request references the folder or file area you want Archibot to use.

Can I use a personal secondary-AI login in an Archibot workspace?

Not through Console-managed workspace setup. Archibot-managed workspaces do not store, copy, or route personal provider account-login files through the workspace harness, and managed secondary-AI options are not exposed as customer-facing setup choices.

If you need another provider-specific assistant today, use that provider’s official CLI in your own workspace shell and log in there directly, outside the Archibot-managed credential flow. This keeps customer billing attribution separate from personal provider subscriptions and avoids uploading account-login payloads from your home directory or shell environment.

For Archibot-style pair programming, use the managed Archibot entrypoint in the workspace. Personal provider logins stay separate and do not change billing attribution.

Missing Account Setup or Analytics navigation

Sign out and sign in again. If the expected navigation is still missing, the account may not be mapped to the customer admin role. Escalate with the user email, company or customer account, expected role, the navigation items you do see, and the approximate sign-in time. See Access roles for what each role can reach.

Customer member cannot see account-wide Analytics

That is expected. Customer members can review their own usage, but account-wide usage belongs to customer admins and platform operators. Ask a customer admin for a customer-level usage review. See Usage and billing.

Analytics looks empty

Check, in order:

1. The selected customer scope.
2. The selected period.
3. Reconciliation status.
4. Whether the workspace was running during the period.
5. Whether provider usage is still delayed.

If the period is correct and usage is still missing, send support the selected period and the visible reconciliation status.

Invite lands on access denied

1. Sign out of the identity provider.
2. Reopen the invite.
3. Complete the invite acceptance flow.
4. Open Console directly after acceptance.

If the invite was already consumed or expired, ask a customer admin or operator to reissue it. Do not paste the invite link into support chat.

Account Setup, Targets shows Waiting on ISM

For shared-hosted tenants, Targets is usually a review-only page. Customer admins confirm the operator-managed target and template-alias readiness there, but do not register or edit target credentials themselves.

If it still shows Waiting on ISM, send support the customer or tenant name, whether Targets is empty or shows a non-ready target, and any visible template-alias or readiness message. See Customer admin setup.

Still stuck

Collect the workspace name, the visible status and any blocker message, the build id from the Support dialog, and a downloaded log file. Then open a case with the detail in Support handoff. Keep secrets, tokens, cookies, and private prompts out of anything you attach.