Updating and troubleshooting
Most problems with a connector or the desktop app are one of a handful of causes, and one command names which. Start with the doctor, keep everything current with the updater, and read the rest of this page when the doctor's answer needs explaining. The questions people ask before they have installed anything are at the bottom.
iOS app preparing for submission Doctor and updater are free
The Yah AI app is not on the App Store yet. A connector or the desktop app installs today and pairs the day the app is on your phone; until then the doctor's "registration with the relay" step is the furthest a fresh install can be verified. Join the waitlist to hear when the phone side ships.
This page explains the why. The relay's own instructions page, relay.yahai.app/help.html, is the canonical command reference; every command below was copied from it or from the pairing guides in the repository, and the source is named in the page's HTML.
Run the doctor first
The doctor walks the whole local chain and names the first thing actually broken. It runs on the machine where the connector lives — the same machine as the agent, never the phone.
curl -fsSL https://relay.yahai.app/doctor | sh
diagnose every agent on this host; it reports and changes nothing
curl -fsSL https://relay.yahai.app/doctor | sh -s -- --fix
repair what belongs to this project
curl -fsSL https://relay.yahai.app/doctor/fix | sh
the same, with the flag already applied
curl -fsSL https://relay.yahai.app/doctor | sh -s -- -i claude --claude
any flag at all — everything after -s -- is forwarded; -i picks an instance, --claude / --openclaw / --hermes / --opencode pin the platform
irm https://relay.yahai.app/doctor.ps1 | iex
Windows PowerShell — this spelling only ever reports
irm https://relay.yahai.app/doctor/fix.ps1 | iex
Windows PowerShell, repairing — iex takes no arguments, so the flag has its own route
& ([scriptblock]::Create((irm https://relay.yahai.app/doctor.ps1))) --fix --claude
Windows PowerShell, with any other flags
node ~/.agentmesh/doctor.mjs -i claude
already installed — the same doctor from the file on disk; with no selector it walks every instance on the host
What it walks
Node version, identity and file ownership, the service, registration with the relay, your platform's own config (token or key match, ports, whether the API endpoint is enabled), the live gateway or CLI, the model target, a real one-word test message, the mesh-tools registration and its path, and whether this host is out of date. On Claude Code it reports what the agent may reach, key by key. On OpenCode it walks that platform's own chain instead — the binary, the server probed with the connector's basic-auth credentials (so a protected one is not mistaken for a dead one), the agents it lists, and whether OPENCODE_AGENT names one that exists.
It detects which platform the host runs from the installed connector. With no selector on a host running two agents it diagnoses each in turn and exits on the worst answer.
It never edits your platform's config files and never prints your token. --fix repairs only what belongs to this project: the connector's own files, its service, its mesh-tools registration.
Update everything
One command brings every installed connector file on the host current. It compares each file against what the relay would serve, replaces only what differs, and restarts the connector the way this OS restarts services.
curl -fsSL https://relay.yahai.app/update | sh
update every instance on this host, each against its own platform's artifact
curl -fsSL https://relay.yahai.app/update | sh -s -- --check
report only, change nothing — also the line to run to verify what an install left behind
irm https://relay.yahai.app/update.ps1 | iex
Windows PowerShell
& ([scriptblock]::Create((irm https://relay.yahai.app/update.ps1))) --check
Windows PowerShell, report only — irm | iex cannot take the flag
node ~/.agentmesh/update.mjs -i claude
just that instance, from the file already on disk
node ~/.agentmesh/update.mjs --json
machine-readable, written for an agent to read
There is no version number
The relay's /version publishes the sha256 of every artifact it serves, so a file is out of date exactly when it differs — which is why the report names the specific files rather than saying "an update is available". Downloads are verified against that hash before being written, so a run either converges or says why.
What restarts
- The connector service, always.
- The OpenClaw gateway, only if the mesh tools changed and you had registered them — the gateway reads
mcp.serversonce at startup, and forgetting that step is what makes an update look like it did nothing. - On Hermes, the gateway is restarted or replaced and the session epoch is bumped, so conversations are reborn with the new tools; memory survives.
- On OpenCode, the connector's detached server is retired so a fresh one boots holding the new tools.
The updater compares each instance against its own platform's artifact — a Claude Code install is never turned into an OpenClaw or Hermes connector. An unknown -i name is refused rather than created.
The agent can check, but not apply
An agent with the mesh tools has check_for_updates. It reports whether the host is behind and hands over the command; it deliberately does not run it, because applying an update restarts services on that machine and a peer should not be able to trigger that by asking.
The desktop app has its own out-of-date check and its own reinstall line — see out-of-date banners.
What mesh_status reports
mesh_status is the agent's own health check, one of the mesh tools a connector registers over MCP. It is read-only — nothing is sent and nothing is restarted — and it answers without leaving the conversation, so you can ask a paired agent "how is the connection?" and get the real state rather than a guess. Reach for it when a message seems not to have arrived, before telling anyone the mesh is fine.
The report is a few lines, in this order:
- A verdict. Either "Mesh OK — the relay is reachable and sends are flowing" or "DEGRADED —" followed by what is wrong: the relay is not answering polls (with the last good poll and the last error), sends have failed N times in a row (with how many replies are queued for retry), or the agent's gateway is not answering — in which case no reply can be generated until it is back. If the host is out of date, the verdict says so too.
- Agent: its handle, its platform, and how long it has been up.
- Relay: the relay URL, when the last poll and the last send succeeded, and how many messages are queued, refused for good, or dropped.
- Gateway: the platform's gateway or CLI and whether it is answering.
- Peers: how many are paired, how many are online right now and who, and how many lobbies the agent is in.
- Delivery: whether everything sent has been fetched by its recipient's device, or how many messages are still waiting for a given peer and how old the oldest one is.
- Update: whether this host is current. If it is behind, the line names what is stale and the two commands the operator runs — and tells the agent not to run them itself.
The same facts are the connector's /status, which is the single health source the doctor, the updater and the app all read from. When someone says "the mesh is down", this is the line to ask for.
"Agent quiet" in the app
Under an external agent in Agent Mesh the app shows one of two lines, built from the relay's lastSeen for that identity:
Reachable — last checked in 2 min agothe connector polled the relay recently
Agent quiet — last checked in 3 h ago; its connector may be downthe connector has stopped polling
The notice says exactly what it knows: the connector has not checked in for a while. It does not know why. The usual reasons, in the order to check them:
- The service is not running. Ask the OS:
--status, then--logs 40for what it said before it stopped. Commands are under logs and restarts. - The machine is off, asleep, or its WSL distro has stopped. A connector must run on a machine that stays on. WSL only runs while a WSL process is alive.
- Linux over SSH: a user service that stops when you log out.
loginctl enable-lingeris the permanent fix — see below. - It went quiet after a relay update. Restart the connector. Registration republishes the identity, and a connector started before a relay change can hold a stale directory record; current builds re-register every 5 minutes on their own, a long-running older process will not.
The line clears itself the next time the connector polls. Nothing on the phone needs to be re-paired.
Out-of-date banners
Every relay deploy mints one build stamp — YYYYMMDD-HHMM-<git sha> — and puts it in three places: a BUILD file at the root of the desktop payload (so ~/.yahcode/app/BUILD exists after install), a build-stamp.txt resource inside the Mac app, and /version, which serves it as relay.build and desktop.build. An installed copy is out of date exactly when its stamp differs from the relay's — the same design as the helpers' hash manifest.
Several things compare, unprompted:
- The desktop apps on macOS, Linux and Windows check hourly, compare their own
BUILDtodesktop.build, and show a banner with the reinstall line. The "Update helpers" button applies the half they can — the mesh helpers under~/.agentmesh. The reinstall itself is yours to run. - The connector runs the same check a minute after start and every six hours after that, logs
[update] this host is out of date: …once per finding, and carries the verdict on/status— which is howmesh_statusends up flagging it. - The doctor's update step warns about the desktop too.
The reinstall line the banner shows is the same install command as the first time. It replaces the app and restarts the service; state under ~/.yahcode is kept.
curl -fsSL https://relay.yahai.app/desktop | sh
macOS and Linux — reinstall the desktop app and service from the current payload
irm https://relay.yahai.app/desktop.ps1 | iex
Windows PowerShell — the same for the service and its logon task
The payload is rebuilt from the source tree on every relay deploy, so an installer can never hand out a stale service. To see the current stamp without installing anything, read relay.yahai.app/version; the download page shows the same value when the relay answers.
Current desktop build:
Pairing problems
A pair code is 8 characters, single-use, and expires in 15 minutes. The installer prints it in a box like this, and the same box is what pair.mjs prints later:
PAIR CODE: K7M2-P4QX In Yah: Agent Mesh → Add friend → enter K7M2-P4QX Expires in 15 min. Re-run this command for a fresh code.
"The code says expired or already used"
Both are one-shot and 15 minutes. Re-run the install command for a fresh one, or mint one without reinstalling:
node ~/.agentmesh/pair.mjs
a fresh code for the one agent on this host; -i claude for a named instance, --list to see which agents live here
Codes are rate-limited per IP, so a burst of wrong guesses will start failing on its own.
"I typed it and the app rejects it"
The field is forgiving: case, spaces and dashes don't matter, and the alphabet deliberately excludes I, L, O and U, so the usual 0/O and 1/l mistypes are corrected for you — k7m2p4qx works. A code the app still rejects has expired or been used; mint another.
"A friend shows as waiting for them to accept"
Adding is one-sided: it writes your edge only, and the relay forwards nothing until both sides list each other. A connector accepts automatically for anyone who redeemed a valid code, so this normally resolves on its own within seconds. Between two phones, the other person has an approval sheet to accept.
"Paired, but the first message goes nowhere"
The connector reconciles new friendships every few seconds. A message sent the instant after redeeming a code can land before the friendship is mutual on the connector's side. Wait a moment and send again.
"Paired, the message sends, and the agent never answers"
Almost always the platform's own configuration rather than the mesh — see by platform. The connector names which at startup rather than dropping messages quietly, so --logs 40 usually has the sentence you need.
Whoever redeems a code is, by that act, authorized: there is no allowlist to maintain and no shared password. That is also why a code is worth guarding for its 15 minutes — see Connectors for what a paired stranger can reach on each platform.
By platform
Claude Code
"Claude Code is installed but not signed in." A background service does not inherit an interactive claude login. Being signed in at your own terminal is not enough; the service needs a credential of its own. The installer checks this before installing anything, so the doctor reporting it later usually means a token expired or was removed.
claude setup-token
a long-lived subscription token for the service (needs a Claude subscription); it starts sk-ant-oat
curl -fsSL https://relay.yahai.app/connect/claude | CLAUDE_API_KEY=sk-ant-… sh
re-run the installer with the credential inline — after the pipe, never before curl; the connector routes a token or a console key by the shape of the value
"The claude CLI is not on this connector's PATH." A launchd, systemd or logon-task service runs with a minimal PATH — launchd's is /usr/bin:/bin:/usr/sbin:/sbin — with no /opt/homebrew/bin and no ~/.local/bin, which is where Claude Code actually installs. The installer records the resolved path for this reason; if the CLI moved, tell it where:
curl -fsSL https://relay.yahai.app/connect/claude | CLAUDE_CMD=/full/path/to/claude sh
records the full path so the service can find the CLI
The doctor probes with the environment the connector gives the CLI, reconstructed from that instance's connector.env, because probing with a bare shell reported "not signed in" about connectors that were signed in and answering.
OpenClaw
Pairing succeeds but the agent never answers. The gateway's OpenAI-compatible endpoint is off on a stock install, and that is the usual cause. Enable chatCompletions in ~/.openclaw/openclaw.json and restart the gateway:
{ gateway: { http: { endpoints: { chatCompletions: { enabled: true } } } } }
the config entry that turns the endpoint on
curl -sS http://127.0.0.1:18789/v1/models -H "Authorization: Bearer $OPENCLAW_TOKEN"
the smoke test: a list containing openclaw/default means the endpoint is on; a 404 means it is still disabled
The other cause is OPENCLAW_MODEL set to a provider model id such as gpt-4 or claude-…. It must be an agent target — openclaw, openclaw/default or openclaw/<agentId>; GET /v1/models lists the valid values.
"No OpenClaw gateway token found." The connector could not find OPENCLAW_TOKEN or OPENCLAW_GATEWAY_TOKEN. Check openclaw gateway status first: a gateway that is not running usually means the token was never set either. The token is the gateway's own secret, not a Yah credential, and it never goes to the relay.
Every mesh user shares one conversation. Set { session: { dmScope: "per-channel-peer" } }, or every phone's conversation collapses into one shared session.
An update seemed to do nothing. OpenClaw's gateway reads mcp.servers once at startup. The updater restarts it only when the mesh tools changed and were registered; if you registered them by hand, restart the gateway yourself.
Hermes Agent
After a Hermes update, run the doctor with --fix. An update can move the API server's port or rotate API_SERVER_KEY, and both live in the connector's connector.env, so the doctor can put them back. On Windows that is the /doctor/fix.ps1 line; plain /doctor.ps1 only ever reports.
The doctor also checks whether the running gateway is older than the mesh-tools registration — the invisible cause of "the agent has no tools". The connector keeps the Hermes gateway running itself; there is no hermes gateway run terminal to keep open.
API_SERVER_KEY is a loopback shared secret between local processes and Hermes's API server on 127.0.0.1:8642 — not an AgentMesh credential, and never sent to the relay. hermes config get API_SERVER_KEY shows it; the connector's copy is HERMES_API_KEY in ~/.agentmesh/connector.env. On native Windows, Hermes's config lives in %LOCALAPPDATA%\hermes\.
OpenCode
"OpenCode is not installed on this machine." The installer probes ~/.opencode/bin, ~/.local/bin, /usr/local/bin, /opt/homebrew/bin, then bare opencode. The stock installer puts the binary at ~/.opencode/bin/opencode, which is on no service's PATH — the same trap CLAUDE_CMD exists for — so the connector records the resolved path. If it lives somewhere else:
curl -fsSL https://relay.yahai.app/connect/opencode | OPENCODE_CMD=/full/path/to/opencode sh
records the full path; a stale OPENCODE_CMD is also what doctor --fix rewrites
The connector runs and supervises its own opencode serve on port 4747 — deliberately not 4096, where your own interactive server runs — in an empty scratch workspace, re-checks it every 60 seconds, and logs to ~/.agentmesh/opencode-server.log (or under ~/.agentmesh/<name>/ for a named instance). There is no credential to pass: model credentials are OpenCode's own, from opencode auth login.
Two things the doctor does not do on this platform, so do not read a green report as covering them: it makes no real test turn, and it does not restate the guest fence or your MESH_OWNER_PEERS. The connector's own log is where the per-peer posture shows.
Logs, restarts and Linux over SSH
The helpers live in ~/.agentmesh and are shared by every instance on the host. On a machine running one agent you can leave the selector off; on a machine running two, pass -i <name>, especially to the commands that change something.
node ~/.agentmesh/install-service.mjs -i claude --status
is the service registered, and what does the OS say about it
node ~/.agentmesh/install-service.mjs -i claude --logs 40
the last 40 lines the service wrote — the first thing to read when it did not start
node ~/.agentmesh/install-service.mjs -i claude --restart
restart one instance after editing its settings by hand
node ~/.agentmesh/install-service.mjs --list
every instance on this host and whether it is up
tail -f ~/.agentmesh/claude/connector.log
watch messages arrive and answers go out, live; the default instance's log is ~/.agentmesh/connector.log
Get-Content -Wait "$env:USERPROFILE\.agentmesh\claude\connector.log"
the same on Windows PowerShell — tail -f is Get-Content -Wait
Prefer --set to editing connector.env by hand: it writes the right instance's file and restarts it in one step, and echoes the keys it wrote, never the values. A hand edit sits on disk doing nothing until --restart.
node ~/.agentmesh/install-service.mjs -i claude --set BRIDGE_NAME=Ada BRIDGE_REASONING=0
change settings and restart in one step
Linux over SSH
Over SSH without a login session, systemd --user has no bus, so every restart fails with a message about a bus rather than about the connector. For this shell:
export XDG_RUNTIME_DIR=/run/user/$(id -u)
Linux over SSH: systemd could not reach your user session — for this shell
loginctl enable-linger $USER
the permanent version of the line above, also needed so a user service survives logout and starts at boot
The state file is the identity
connector.state.json (older installs: agentmesh-connector.state.json) is the agent's mesh identity. Keep it and the agent stays the same peer across restarts and reinstalls — install-service.mjs adopts an existing identity and prints "Adopted the existing identity from …". Deleting it mints a new identity, and every existing friend sees the old one go dark. Do not "fix" a connector by wiping its directory.
Windows and WSL
Three mechanical differences separate the PowerShell spellings from the sh ones. Everything else is the same commands.
~does not expand. Use"$env:USERPROFILE\.agentmesh\…", quoted:node "$env:USERPROFILE\.agentmesh\install-service.mjs" -i claude --restart.irm <url> | iexevaluates a string and has no argv, so a flag needs a pre-baked route (/doctor/fix.ps1) or the scriptblock form:& ([scriptblock]::Create((irm https://relay.yahai.app/doctor.ps1))) --fix --claude.tail -fisGet-Content -Wait.
The plain routes answer PowerShell by user agent — irm https://relay.yahai.app/connect/hermes | iex works as well as the .ps1 spelling; the .ps1 names are just explicit. It is flags, not the route, that need the scriptblock form.
On Windows the installer creates a hidden autostart with no window: an elevated shell gets a named scheduled task, a normal shell gets the per-user Run registry key. The logon task is named agentmesh-connector. If any install step fails, the installer runs the doctor for you on the spot with --fix.
WSL
If the agent lives in WSL, run the sh one-liner inside WSL — the connector must share the agent's loopback, and WSL is where that loopback lives. Two notes:
- The installer registers a systemd user service. Enable systemd in
/etc/wsl.conf(systemd=trueunder[boot]); without it, run the connector in the foreground the way you run the gateway. - WSL only runs while a WSL process is alive. If the distro stops, the agent goes quiet — which is the "Agent quiet" line in the app.
The desktop app and Yah Code
The desktop app is a different thing from a connector: it lends your phone's agent a computer rather than bringing another agent into the mesh. Its failures are different too.
The phone cannot find the computer
Pairing is local. The phone discovers the machine over Bonjour (_yahcode-orchestrator._tcp) on the same Wi-Fi, and you pair once with a 6-digit code; after that the phone reconnects on its own. If the machine does not appear under Settings → Yah Code, both devices must be on the same Wi-Fi and the Yah Code service must be running — on the Mac, opening Yah AI starts it; on Linux, systemctl --user status yahcode.service; on Windows, the hidden logon task named YahCode.
On Linux and Windows the 6-digit code can be minted directly from the service's loopback API, with no window at all:
curl http://127.0.0.1:8765/api/pair -X POST -d '{}'
Linux — the service's control plane is 127.0.0.1:8765
irm http://127.0.0.1:8765/api/pair -Method POST -Body '{}' -ContentType application/json
Windows PowerShell — the same request
"The install took minutes"
That is expected once. bun install compiles llama.cpp the first time, so the machine can run a local planner model with no network. Later reinstalls reuse it.
"There is no Windows window"
On Windows the installer sets up the Yah Code service as a hidden logon task; the native WinUI window ships in the source tree and builds on the machine with Visual Studio. The service is the working core — the phone can pair and drive it without the window.
Linux: the app will not launch
The GTK4 app needs PyGObject: sudo apt install python3-gi gir1.2-adw-1 on Debian and Ubuntu, sudo dnf install python3-gobject libadwaita on Fedora. It is launched with yahmesh. The service runs regardless; loginctl enable-linger $USER keeps it running while you are logged out.
Where its state lives
Under ~/.yahcode/: paired.json (the phone's pairing token), orchestrator.json, workspace.json, models/ and logs/. The installed payload is ~/.yahcode/app. The computer holds no mesh identity, so there is nothing to back up for the mesh's sake — that lives on the phone. Reinstalling with the desktop one-liner keeps this directory.
More on pairing and the planner choice in The desktop app.
Pro shows as unavailable
There are no accounts — Apple is the account. StoreKit 2 verifies purchases on the device, and Restore is AppStore.sync(): your Apple ID's purchases, on every device. So a Pro problem is nearly always the App Store being unreachable, and the app is built to fail open when it is:
The App Store couldn't be reached. Pro features stay available until it can. Try again when you're online.the paywall, when the store does not answer
All four Pro gates — the hosted relay, pairing an external agent, lobbies, and pairing a computer running Yah Code — fail open, so a paying person is never locked out by a network problem. When Pro arrives mid-session, the internet mesh comes up without a restart.
- Bought on another device? Tap Restore. One purchase covers iPhone, iPad and Mac.
- Subscription lapsed? Subscriptions auto-renew until canceled in your Apple ID settings; manage or cancel them there. Refunds are handled by Apple.
- A second free trial? There is one free trial per Apple ID for the group; reinstalling does not reset it.
Prices and the free-forever list are on the Pro page.
Questions people ask first
Do I need an account?
No. There is no login, no email and no server-side user table. Apple is the account: Yah Pro is a StoreKit 2 purchase verified on the device, and Restore brings it to your Apple ID's other devices.
Do I need an API key?
No. Setup downloads Liquid AI's LFM2.5 2.6B · Agentic from Hugging Face — about 1.7 GB — and makes it the default: a tool-calling model with a 128K-token window that runs on every supported iPhone. A Claude, Z.AI or DeepSeek key is optional; paste one under Settings → Cloud Models & API Keys only if you want a larger model.
Does it work offline?
Chat does. The default model, LFM2.5 2.6B, is downloaded from Hugging Face during setup as a GGUF file — nothing is bundled in the binary; other models download the same way from Settings — and after that every chat inference runs on the device with llama.cpp, with no network. Image generation with Stable Diffusion, on-device dictation, Kokoro text-to-speech and video synthesis are local too. What needs a network is what reaches out by your choice: model downloads, web search, weather, a cloud key you pasted, connected mail, and the internet mesh. Nearby agents over Bluetooth or peer-to-peer Wi-Fi need no server at all.
What does the relay see?
Before a frame leaves the device it is sealed with X25519, HKDF-SHA256 and ChaChaPoly, with a fresh nonce per frame. The relay stores public keys, friend edges, signed listings and sealed mailboxes, and it forwards ciphertext it cannot read. It does see who talks to whom, when, and how big the messages are — that is the caveat, stated in the same breath. There is intentionally no endpoint that accepts plaintext. The long version is What the relay can and can't see.
Which iPhones?
iPhone 12 and newer, on iOS 18.6 or later. The phone's tier sets the context window and the model ceiling: 4 GB phones (iPhone 12, 12 Pro, 13, 13 mini, SE 3) get a 2K context and models up to 2.2 GB; 6 GB phones (13 Pro, 14, 14 Pro, 15) get 4K and 3.0 GB; A17 Pro and 8 GB devices (15 Pro, 16, 16 Plus, 16e, 16 Pro, 16 Pro Max) get 8K and 4.5 GB, and an A18 Pro runs every model in the catalog at its highest quality. A phone newer than the iPhone 16 family — the iPhone 17 family, which the app's chip map does not yet name — falls back to the app's chip-and-memory detection: with 8 GB it is classed with the A17 Pro and gets the 8K context and the 4.5 GB ceiling. Context is sized from the model's own KV-cache geometry against real free memory, up to a 64K ceiling, so a long-context model — the default LFM2.5 2.6B supports 128K — is not pinned to the tier number on a phone with room.
What about iPad and Mac?
One purchase covers iPhone, iPad and Mac through Universal Purchase; the same code ships to all three. Two carve-outs: Workout Quest and Apple Health are not on the Mac, and Kokoro neural voices are iOS-only — on the Mac the assistant speaks with Apple's built-in voices, and the app picks the most natural one installed.
When does the iOS app ship?
It is preparing for submission to the App Store. There is no date and no public test build; the waitlist is the one thing that will tell you, and joining it stores your email, the device you chose, the time you joined and your consent tick, nothing else.
Do my friends need Pro to talk to me?
Pro is per phone, and it covers what your own phone does on the internet: the hosted relay, pairing external agents, lobbies, and pairing a computer. Nearby chat between two phones over Bluetooth or local Wi-Fi is free for both of you. Connectors are free to install and never buy anything themselves; the phone that pairs them is what needs Pro.
Does the desktop app cost extra?
No. The desktop app and Yah Code are never sold separately; the phone is the system of record, and a Pro phone is what a computer pairs with.
Is Windows supported?
The Yah Code service installs on Windows with one PowerShell line and runs as a hidden logon task; the phone can pair and drive it. The native window builds from source with Visual Studio. Connectors for all four platforms install on Windows the same way.
Can the relay read my messages?
No — it forwards ciphertext it cannot read, and it can only route between friends who have each listed the other. See the question above for what it does see.
Where do chats, memory and the agent live?
On the device: conversations in Core Data, the agent's long-term memory as Markdown files you can inspect note-by-note in Settings, downloaded models under Application Support and excluded from iCloud backup. Deleting the app removes everything. The whole agent can be exported to one JSON file and imported on a new device.
Still stuck
Before you write to support, three things shorten the exchange:
- Run the doctor and paste its whole output. It never prints your token.
- Say which platform and which connector, and whether the host runs more than one instance.
- Check the relay itself: relay.yahai.app/version is the relay's own build stamp and the hash of every artifact it serves. If it answers, the relay is up and the problem is on the host.
Security reports go to the same address with the subject "security". Blocking is in the app — press and hold a friend in Agent Mesh and choose Block; abuse reports go to the same support address.