# Ccb Mobile Relay Maintain

> Diagnose and safely maintain the CCB Mobile host service, LAN/tailnet/Cloudflare Tunnel/Relay routes, pairing and devices, Relay invitation or host activation, multi-project terminals, and capability-negotiated Provider controls. Use when Mobile cannot connect, pair, discover projects, open terminals, expose Provider controls, or when a user explicitly asks to activate, update, revoke, or repair a CCB Relay host or device.

- Skill: `seemseam/ccb-mobile-relay-maintain` (Agent Skill)
- Install (CLI): `npx skillmds@latest add seemseam/ccb-mobile-relay-maintain`
- Raw SKILL.md: https://api.skillmd.com/api/skills/seemseam/ccb-mobile-relay-maintain/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: seemseam (https://skillmd.com/u/seemseam)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/seemseam/ccb-mobile-relay-maintain

---


# CCB Mobile Relay Maintain

Read `references/ccb-mobile-relay-runtime.md` before mutation. Keep the Mobile
host's server-wide authority separate from project runtime and Pane evidence.

## Safety Rules

- Never read, print, store, or request Relay credentials, invitation secrets,
  device secrets, Provider credentials, or raw Provider responses in chat or
  Role memory.
- Diagnose before replacing the host or rotating pairing state.
- Revoke only one exact device, invitation, or host after explicit user intent.
- Do not infer Mobile host health from a project Pane or `.ccb/agents/*`.
- Do not force Provider controls when capability negotiation says unsupported;
  report the required host update.

## Workflow

1. Classify the incident:
   - host service not running or unhealthy;
   - LAN/tailnet/tunnel/Relay route unreachable;
   - pairing handoff expired or unclaimable;
   - device unauthorized or intentionally revoked;
   - running project not discovered;
   - host or project terminal transport failed;
   - Provider controls hidden, rejected, or pending restart;
   - native Windows registry, endpoint, TCP descriptor, or readiness mismatch.
2. Collect sanitized evidence with the smallest applicable commands:

```bash
ccb mobile devices
ccb relay host status <host_id>
ccb relay host list
ccb relay invite status <invite_id>
```

   Use local health and managed-service diagnostics when available. Do not
   expose secret-bearing files or arguments.
3. Verify the active service generation, CCB ownership of the listen endpoint,
   selected route provider, registered projects, and advertised capabilities.
4. Choose the least disruptive supported action:
   - `ccb update mobile` to refresh the server-wide host or rotate an expired
     pairing handoff;
   - `ccb mobile revoke <device_id>` for one explicitly selected device;
   - `ccb relay host activate ...` only from an operator-provided invitation or
     invitation file already available through the authorized workflow;
   - exact `ccb relay ... revoke` only for an explicitly selected identifier.
5. For Provider setting changes, distinguish configured, active, and pending
   state. Hand guarded post-config Agent restart to `ccb-self-recover` when the
   host says restart is required.
6. Verify health, route, project discovery, terminal connection, and capability
   negotiation after mutation.

## Native Windows

Use native Windows process ownership, registry, TCP descriptor, endpoint
marker, readiness, and Herdr namespace evidence. Do not apply Unix tmux or
`/proc` assumptions. If the current release reports beta prerequisites or an
unsigned launcher boundary, preserve that status in the report.

## Output

Report:

- incident class and current route;
- sanitized host generation/health evidence;
- project discovery and terminal status;
- capability status and any host-update guidance;
- exact mutation performed, if any;
- identifiers revoked without secret material;
- remaining platform or external-network blocker.