Troubleshooting

If something feels wrong, start here:

jarvis doctor
jarvis status
jarvis logs -n 200

Those three commands solve a large percentage of first-line debugging.

Daemon Does Not Start

Symptoms:

• jarvis start exits immediately
• jarvis status stays stopped
• nothing opens on port 3142

What to check:

1. Port already in use:

lsof -i :3142

2. Broken config or missing provider credentials:

jarvis doctor

Notes on doctor results:

• “Config File: Not found” is expected on a fresh install; Usejarvis runs on defaults until you create one
• “No providers configured” means you have not added an LLM yet: do it in Settings → LLM
• A config file that exists but has invalid YAML is a fatal startup error

3. Read logs:

jarvis logs -f

Dashboard Shows Disconnected

Symptoms:

• The UI loads but the sidebar says disconnected
• chat does not stream

Likely causes:

• The daemon is not actually running
• You opened the wrong host or port
• A reverse proxy is not forwarding WebSocket upgrades
• You are not connecting through an enrolled sidecar. The dashboard requires a sidecar-minted access token; the enrollment JWT itself is not accepted on /ws or /api. Open the dashboard through the sidecar, or set auth.insecure_open_access: true temporarily during setup.

If you use Nginx or another proxy, make sure both /ws and /sidecar/connect are upgraded correctly.

Browser Tools Do Not Work

Symptoms:

• Usejarvis says it cannot use the browser
• navigation tasks fail

Check:

• Chrome, Brave, Edge, or Chromium is installed
• The daemon can launch the browser on the host where it is running
• You are not assuming the VPS can control a browser on your laptop without a sidecar
• On headless servers, set browser.local: false in config.yaml so browser actions route to a connected sidecar instead of trying to launch locally

Sidecar Does Not Connect

Symptoms:

• desktop or filesystem actions fail
• the Sidecar settings area never shows the machine online

Check:

• The sidecar token is correct
• daemon.brain_domain is set to a URL the sidecar can actually reach, with an explicit scheme. A bare host:port defaults to wss/https, which fails against a plain-HTTP daemon. Changing brain_domain requires re-running jarvis enroll; old tokens keep the old address.
• The sidecar can reach the daemon over the network
• Firewalls are not blocking the connection

The “Can Your Computer Reach This URL?” Error

This is one of the most common remote-hosting mistakes and it affects Ollama, local Whisper endpoints, and any other service URL you configure.

Why It Happens

People often host Usejarvis on one machine but leave provider endpoints set to localhost, for example the Ollama base URL in Settings → LLM or the local STT endpoint in Settings → Voice pointing at http://localhost:11434. (These are dashboard settings since 0.9; editing an llm: block in config.yaml has no effect.)

That only works if:

• Usejarvis is running on the same machine as Ollama or Whisper

If Usejarvis runs on a VPS and Ollama runs on your desktop, then localhost means:

• the VPS itself

not:

• your desktop
• your browser
• your laptop

So the daemon tries to connect to a service that does not exist on the VPS and you get reachability failures.

How to Fix It

Use a URL the daemon can actually reach:

• a LAN IP like http://192.168.1.50:11434
• a Tailscale address
• a reverse-proxied hostname
• a public/private server IP if your network model allows it

Example: set the Ollama provider’s base URL in Settings → LLM to http://192.168.1.50:11434, or the local STT endpoint in Settings → Voice to https://whisper.example.com with server type openai_compatible.

Reverse Proxy Option

If the service should stay on another machine, put a reverse proxy in front of it and point Usejarvis at that stable hostname instead of localhost.

Example pattern:

• Ollama host runs locally on 127.0.0.1:11434
• Nginx or Caddy exposes it at https://ollama.example.com
• Usejarvis config uses https://ollama.example.com

This works because the daemon can resolve and reach that hostname over the network.

Security Warning

Do not expose Ollama or a local Whisper server publicly without authentication and network controls. If you reverse proxy them, secure the endpoint deliberately.

Docker-Specific Problems

”It Works on the Host but Not in Docker”

Inside Docker, localhost means the container, not the host machine.

That affects:

• Ollama
• local Whisper
• any side service the daemon is trying to call

Fix Options

Option 1: run the dependency in another reachable container/network and use its container name or service hostname.

Option 2: point the daemon at the host machine’s reachable IP instead of localhost.

Option 3: expose the dependency through a reverse proxy hostname and use that URL.

Desktop/Browser Limitation in Docker

The containerized daemon does not magically gain full control of your host desktop/browser environment. Use sidecars on the target machines for real desktop/browser reach.

Ollama-Specific Problems

Usejarvis Cannot Reach Ollama

Check:

• Ollama is actually running
• the base URL configured in Settings → LLM is reachable from the daemon machine
• the model exists locally (the dashboard lists exactly what you have pulled)

Useful checks:

curl http://localhost:11434/api/tags
ollama list

Replace localhost with the actual address Usejarvis should use.

Local Whisper / STT Problems

Local STT Endpoint Fails

Check:

• endpoint is reachable from the daemon machine
• server_type matches the server you are using
• the endpoint path is correct for that server implementation

If the daemon is remote and Whisper is local to your laptop, do not leave the endpoint as localhost unless the daemon is running on that same laptop.

Reverse Proxy Checklist

If you host the dashboard or related services behind a proxy:

• forward the daemon port correctly
• forward WebSocket upgrades for /ws and /sidecar/connect
• keep /health, /sidecar/connect, and /api/sidecars/.well-known/jwks.json publicly reachable
• verify the host the browser sees matches the host your deployment expects
• preserve cookies and x-forwarded-proto

Also note: on a plain-HTTP LAN dashboard, browsers block microphone and clipboard access (secure-context policy). No config fixes that; use an SSH tunnel, Tailscale, or a local CA.

If You Still Cannot Fix It

Collect these before asking for help:

jarvis status
jarvis doctor
jarvis logs -n 200

And include:

• where the daemon runs
• where Ollama/Whisper runs
• whether Docker is involved
• whether a reverse proxy is involved
• the exact configured URL

Community

If you want another set of eyes, use the Discord server:

• https://discord.gg/ytG2PHQ6rW