Agent is offline or work has stopped

Identify which part stopped

Open the agent profile and check its computer state and Activity. Then inspect the specific conversation or task. An online agent may be waiting for access or human approval rather than doing more work.

Cloud agent is preparing or offline

• Check whether computer provisioning is still in progress or has reported an error.
• If the Computer tab shows a runtime update or capability error, use Update & repair. Compare the running and target Bridge versions; installation alone does not prove the service has restarted into the new version.
• Look for a pending access request or handover before retrying the task.
• If the profile offers a recovery action, use it on that existing agent.
• If setup stays failed, report the profile and visible error to your workspace administrator or CrewX support.

Do not run local Bridge commands on your laptop to repair a managed cloud computer. Do not delete and recreate an agent just to clear a status: that changes its identity and can discard useful evidence.

Connected agent is offline

Bridge 0.2.74 or newer automatically recovers an expired heartbeat connection. It stops the stale runner before CrewX issues a fresh session, keeps the same agent and approved folder, and resumes saved messages. Conversation context is preserved. CrewX never starts a second runner before the old one stops.

If recovery needs a retry, choose Reconnect agent in the conversation banner or the agent's Computer tab. Waiting for your computer means the machine must be awake, reachable, and running Bridge. Folder or permission changes, deactivated agents, and revoked machines still require their specific setup issue to be resolved. Recovery does not expand access.

For an older Bridge, run crewx-bridge update on the connected machine first. Use the diagnostics below if reconnection still fails.

On the machine that owns the runtime, run:

crewx-bridge service status
crewx-bridge status
crewx-bridge doctor
crewx-bridge runs --all

If Bridge is online but the agent is offline, open the existing profile’s connection controls and start it on the approved machine and folder.

If Create and start agent saved a profile but launch was refused, resolve the visible issue and choose Start saved profile to retry that same profile. If creation or start could not be confirmed, check Agents and the profile's Computer panel first. CrewX does not automatically resend the request.

The Computer panel shows why Restart unavailable, Machine offline or Upgrade Bridge blocks a request. A submitted restart refused by the server shows a persistent Restart not queued explanation. Resolve that issue and choose Restart agent explicitly; a fresh heartbeat does not retry it. An undetected runtime is a launch-readiness problem, not proof of failed provider authentication.

Check that the runtime is installed and signed in, the folder still exists, the selected permission mode is allowed, and capacity is available. A background service may have a different PATH from your interactive shell.

Use crewx-bridge verify codex or crewx-bridge verify claude for an actual provider check under the service's runtime settings. This uses normal provider quota in a temporary workspace. An installed runtime has not necessarily been authenticated or checked with a usable model. Follow the provider-specific advice from verification, then retry the existing agent.

To check the existing profile's saved provider and model, use its profile ID:

crewx-bridge agents list
crewx-bridge verify --agent PROFILE_ID

Replace PROFILE_ID with the ID from the list and save any profile changes before checking again. This requires your CrewX management sign-in.

For a foreground connection, or before enrolling the machine, Bridge 0.2.67 or newer supports an explicit terminal check:

crewx-bridge verify codex --environment interactive

Add --model <model-id> if the provider's default model is unavailable. This provider-only check needs no enrollment or service and reports the interactive environment. It does not prove background-service readiness; ordinary verify continues to use configured_service_launch with no terminal fallback. For foreground setup, run crewx-bridge serve, keep that terminal open, and confirm a fresh machine heartbeat and a reply in CrewX. Setup with install --no-service --verify checks a selected agent in the interactive environment before you start serve.

CrewX refuses OpenClaw's ACP route because it cannot bind the Gateway's actual agent and tool workspace. Before using native OpenClaw, upgrade to Bridge 0.2.66 or newer (bundled CLI 0.2.42) or, for direct terminal runners, CLI 0.2.42 or newer, then restart/reconnect. For a background Bridge:

npx crewx-bridge@0.2.74 update --to 0.2.74 --repair
npx crewx-bridge@0.2.74 service status

Confirm a fresh 0.2.66 or newer service heartbeat. An older client can appear online while still missing the execution-folder safeguard.

Bridge 0.2.70 or newer checks that agents are idle before changing packages or restarting. If it reports active work, let that work finish and run the update again. Restore the machine connection first if CrewX cannot confirm readiness. An interrupted installation briefly holds new assignments; the hold expires five minutes after its last successful preparation.

Change an existing OpenClaw ACP profile explicitly to the native runtime and select its agent ID. Check that agent's approved workspace, provider authentication, and run log before retrying it. Stop existing runs and terminal connections before saving. If a connection crashed, deactivate the profile to close its sessions, wait for assignment leases to expire or cancel parked work, save the native profile, then reactivate and reconnect. Saving the change revokes previous connection tokens.

If Hermes reports that conversation history could not be restored, check its version and configured state directory. Repair its local history or start an explicitly new CrewX conversation. CrewX stops before sending the next prompt when the expected history is missing; retrying preserves the existing session binding. A canceled first turn can still resume when its user history exists.

For a rejected CrewX management sign-in, use crewx-bridge login --force. This repairs the terminal's management sign-in; it does not repair a revoked machine enrollment or an expired provider login. If a machine was revoked intentionally, enroll it again with authorization from the workspace administrator.

A request was claimed but no result arrived

Inspect its latest activity before sending it again. Common causes include model/provider errors, expired authentication, a failed tool, a runtime exit, or a pending user step.

Independent conversations can use available concurrent capacity, but sending the same task twice can create duplicate external work. Check for existing emails, files, PRs, or deployments before retrying.

A cloud model reply failed

If the request reports a model transfer failure, inspect that failed conversation or task's activity and any files or external work it produced. Review model usage and reserved credits separately; usage can remain unresolved after work stops. Include the profile, failed request and visible error when asking your administrator or CrewX support to investigate.

Use Update & repair when the Computer tab reports a runtime error or a running-version mismatch. Starting a fresh attempt after a model failure is a separate decision: inspect the existing work and usage first, then deliberately request another attempt when appropriate. A healthy computer or restarted service does not establish a completed model answer.

A computer preview will not accept input

The normal preview is view-only. For an authorized handover, choose Take over, complete the necessary step, and use Give control back. Opening a larger view is not itself permission to take control.