Віддалене керування та мобільний клієнт

Control Center — застосунок для комп’ютера, але робота, за якою він стежить, не зупиняється, коли ви відходите від столу. Віддалене керування сполучає ваш телефон із вашим cc_server через Remote — супровідний застосунок на remote.usectrl.dev, — щоб ви могли стежити за флотом звідти: читати повідомлення й тікети, відповідати агенту, розбирати стрічку новин, і при цьому аудіо, транскрипт, вихідний код і облікові дані, що лежать на сервері, ніколи його не покидають.

Сприймайте його як супровідний засіб до робочого столу, переважно для читання. Він не покликаний замінити повноцінний настільний клієнт.

Транспорт

Телефон дістається cc_server по WebSocket: або прямим з’єднанням (loopback, локальна мережа, tailnet або wss://), або через кімнату за запрошенням на сигнальному брокері, який ретранслює запечатані кадри. Каналу даних безпосередньо між пристроями немає.

Що вміє телефон

Спарований телефон дістає невеликий, навмисно окреслений зріз можливостей сервера:

Читати тікети, агентів, простори, їхні повідомлення та вашу стрічку новин
Відповідати: надіслати повідомлення в просторі, оновити або призначити тікет, позначити статтю прочитаною чи збереженою
Запустити плейбук: інстанціювати збережений шаблон плану з його параметрами. Це лише пропонує план; нічого не виконується й не витрачається, доки оператор не схвалить його в Plan Studio у повноцінному клієнті
Перемикати робочі простори — з власного засобу вибору на телефоні

Це майже все. Телефон — принципал із нижчими привілеями, ніж повноцінний клієнт. Він не може запускати процеси, витрачати бюджет LLM, надсилати зміни в GitHub чи створювати робочі простори. Про те, як це забезпечується насправді, а не лише задумано, див. модель доступу.

Як будується з’єднання

З’єднання йде через реле з брокером: сервер як власник заходить в одну кімнату за запрошенням на брокері wss://, і кожен спарований клієнт — настільний, веб, телефон — заходить у ту саму кімнату з токеном допуску, обмеженим у часі. Складається це з трьох частин:

Частина	Роль
Remote (телефонний застосунок)	Супровідний вебзастосунок, розміщений за замовчуванням на `remote.usectrl.dev`, або розміщений самостійно. Завантажується в браузері, тримає запис спарювання в IndexedDB.
Брокер реле	Безстанове реле `wss://` (`cc_signaling_server`), що обслуговує кімнати на N учасників. Воно переносить лише непрозорі кадри: кожне навантаження запечатане наскрізним шифруванням між телефоном і сервером, тож брокер ніколи не бачить даних застосунку чи секрету спарювання і ніколи не тлумачить те, що пересилає.
`cc_server`	Власник кімнати. Він відповідає на виклики телефону через той самий диспетчер, який використовують усі інші клієнти.

Пропозиція спарювання містить дескриптор з’єднання зі списком усіх шляхів до сервера (локальна мережа, tailnet, публічний wss://, реле) та відбитком його ідентичності. Резолвер телефону обирає найкращий доступний шлях і закріплює відбиток під час першого з’єднання (TOFU); реле гарантує зв’язок, навіть коли прямого шляху немає, і при цьому ніколи не може прочитати трафік.

Що являє собою навантаження спарювання

Спарювання створюють у застосунку й доставляють як глибоке посилання; процедуру див. у Прив’язати пристрій. Тут важлива його анатомія.

https://<pwa-host>/#<payload>

Навантаження їде у фрагменті URL — частині після #, яку браузери ніколи не надсилають на сервер, тож HTTPS-хост PWA його не бачить. Воно містить усе, що потрібно телефону, щоб дістатися сервера й довести, хто він: дескриптор з’єднання (усі шляхи плюс відбиток ідентичності), щойно створений ідентифікатор пристрою, 32-байтовий попередньо спільний ключ і позначку строку дії. Телефон його декодує, зберігає запис спарювання локально та прибирає фрагмент, щоб секрет зник з URL.

Є дві форми навантаження, і вони не взаємозамінні. QR-код телефону, створений із панелі спарювання в застосунку, — це описаний вище PairingPayload v2, націлений на хост Remote PWA. cc_server pair --client-url створює інше, старіше посилання v1 ({s, i, k} — URL сервера, ідентифікатор пристрою, ключ), призначене лише для вебклієнта.

Вони також різняться строком дії, у чому легко помилитися:

Ким створено	Строк дії облікових даних
Панель спарювання в застосунку (`pairing.mint`)	30 днів, завжди
`cc_server pair` у командному рядку	Немає — облікові дані не спливають

Модель доступу

Спарований пристрій автентифікований, але недовірений. Кілька незалежних шлюзів не дають схваленому (або злитому) спарюванню перетворитися на повний контроль над сервером.

1. Межа — це членство, а не спарювання

Дійсний ключ спарювання доводить, який пристрій ви є. Те, що ви можете читати чи змінювати, визначають ваша роль у робочому просторі, яку перераховують під час кожного окремого виклику, та дозволи на окремі репозиторії для всього, що відкриває вміст репозиторію. Пристрій із цілком робочим ключем, але користувач якого не є учасником названого робочого простору, отримує відмову «Not a member of this workspace».

Мінімальна роль виводиться з виду операції, якщо вона не оголошує власної: читання потребує guest, зміни — member, руйнівні операції — admin.

2. Телефон — це нижчий рівень сеансу

Окрім перевірки ролі, телефонний сеанс має менші можливості, ніж настільний або вебсеанс. Операції, оголошені як доступні лише повноцінному клієнту, відхиляються для телефону до запуску обробника, хоч би який привілейований користувач за ним стояв: створення, перелік, перейменування та відкликання спарювань пристроїв; читання й налаштування тунельного з’єднання; резервне копіювання сервера та експорт/імпорт робочого простору; виявлення й завершення процесів; перевірка адаптерів; налаштування сервера; адміністрування SSO; керування флотом; а також перехоплення агента, що виконується, чи повернення його назад.

3. Список дозволених інструментів із забороною за замовчуванням

Саме для поверхні інструментів MCP (tools/call) тим, які інструменти телефон може викликати, керує список дозволених із забороною за замовчуванням. Усе, чого немає в списку, відхиляється до запуску. Список здебільшого про читання й спостереження, плюс кілька суто локальних записів — повідомлення, оновлення тікета, позначка статті, — які не витрачають бюджет LLM, не запускають процесів і не торкаються зовнішніх систем.

Відмовлено, наприклад: консультація з агентом, запуск ШІ-перевірки, завершення агента, публікація перевірки в GitHub, наймання чи звільнення агентів, створення робочого простору.

4. Прив’язка до робочого простору на кожен виклик

Сервер не тримає «поточного робочого простору». Він за задумом безстановий: кожен виклик у межах робочого простору має назвати свій цільовий workspace_id в аргументах, і диспетчер відхиляє виклик одразу, якщо його немає або якщо названо робочий простір, якого сервер не зареєстрував, — ще до того, як щось відкриє базу даних. Тож телефон ніколи не може успадкувати межі іншого клієнта чи з’їхати в них, і назвати чужий робочий простір теж не зарадить, бо перевірка членства зі шлюзу 1 усе одно діє. Це той самий інваріант ізоляції робочих просторів, якого дотримується решта продукту.

5. Кадри, запечатані наскрізним шифруванням під попередньо спільним ключем

Кожен кадр між телефоном і сервером запечатано ключем спарювання; токен допуску лише впускає клієнта в кімнату, він нічого не розшифровує. Брокер ретранслює шифротекст і ніколи не бачить ключа. Відкликаний пристрій виявляє, що його облікові дані вже зникли, тож під час повторного з’єднання він відмовляє, а не пропускає.

Облікові дані, створені в застосунку, обмежені 30 днями; після цього шлюз з’єднання їх відхиляє, і телефон має спаруватися заново. Відкликання діє наживо: сервер стежить за таблицею пристроїв і розриває відкриті сеанси відкликаного пристрою за секунди, а не чекає на його наступне з’єднання.

6. Обмеження швидкості на принципал

Обмежувач із ковзним вікном тримає віддалений трафік інструментів на рівні 120 викликів за хвилину, з тугішим підлімітом у 30 на хвилину для змінювальних дій. Бюджет належить принципалу, а не сеансу: три ваші пристрої вичерпують один спільний ліміт, тож викрадений клієнт не може купити запас, відкриваючи більше сеансів, а один галасливий учасник не може заморити голодом інших.

7. Брокер, який нічого не дізнається

Брокер реле навмисно примітивний: він обслуговує кімнати, пересилає запечатані кадри й не тримає ні облікових записів, ні даних застосунку, ні ключів. Кімнати доступні за запрошенням і тимчасові. Дані застосунку, аудіо, транскрипт, вихідний код і облікові дані — усе залишається на сервері.

Оновлення наживо

Після спарювання телефон отримує оновлення наживо як кадри сповіщень — нові повідомлення агентів, призначені вам тікети, зміни стану, — дзеркалячи власні сповіщення робочого столу. Сервер розсилає ці кадри кожному з’єднаному сеансу, а фільтр робочого простору застосовується на клієнті, тож те, що ви бачите, обмежено робочим простором, на який ви дивитеся.

Де це розташовано

Поверхня	Що вона показує
Налаштування → Ви → Ваші пристрої (`/workspaces/:workspaceId/settings/you/devices`)	Спаровані клієнти зі станом наживо, а також Спарувати новий клієнт (веббраузер, настільний застосунок або телефон) і відкликання

Та сама панель створює спарювання для другого браузера чи настільного застосунку, не лише для телефонів — процес ідентичний, різниться тільки глибоке посилання.

Див. також

Робочі простори та ізоляція: прив’язка на кожен виклик, на яку це спирається
Спільна робота — ідентичність, членство та присутність: ролі, членство та дозволи на репозиторії
Розгортання та клієнти: де віддалене керування стоїть серед рівнів клієнтів
Архітектура: де віддалене керування стоїть у стеку
Прив’язати пристрій