Worker troubleshooting
The render worker won't start, won't connect, or jobs fail — fixes here.
### Symptom: worker won't start (Mac)
```
"vibeedit-worker" can't be opened because Apple cannot check it for malicious software.
```
We are working on Apple notarisation. Until then:
```bash
xattr -d com.apple.quarantine ~/Downloads/vibeedit-worker-darwin-arm64
```
Then double-click again, or run it directly: `./vibeedit-worker-darwin-arm64`.
### Symptom: "VIBEEDIT_TOKEN required"
The binary needs an auth token to claim render jobs from your account. Get one from **/app/settings → "Local worker"** and paste it:
```bash
export VIBEEDIT_TOKEN=mh_wt_xxxxxxxxxxx
./vibeedit-worker-darwin-arm64
```
On Windows, set the env var in PowerShell: `$env:VIBEEDIT_TOKEN="mh_wt_..."`.
### Symptom: worker connects but never picks up jobs
1. Confirm you see "Worker online" in the editor header. If not, the token may be revoked.
2. Generate a new token in settings.
3. The cloud may be routing your jobs to its own pool — check the render history page. The job dropdown lets you target your local worker explicitly.
### Symptom: renders fail with "hyperframes: command not found"
The worker needs the hyperframes CLI on PATH. The Mac/Linux installer bundles it. If you customised `VIBEEDIT_HYPERFRAMES_CMD`, double-check the path resolves:
```bash
echo $VIBEEDIT_HYPERFRAMES_CMD
which hyperframes
```
### Symptom: renders are slower than the cloud
Likely your machine is on battery / thermally throttled. Plug in. Close other browser tabs. The headless Chrome instance the worker spawns is memory-heavy (~2GB peak for a 60s render).
### Verify a worker job locally
```bash
export VIBEEDIT_URL=https://vibeedit.video
export VIBEEDIT_TOKEN=mh_wt_xxxxxxxxxxx
./vibeedit-worker-darwin-arm64 --once
```
The `--once` flag claims one job, runs it, and exits with a verbose log.
### Still stuck?
Email **support@vibeedit.video** with the worker log and your worker ID (printed on startup).