Zdalne sterowanie i mobile

Control Center to aplikacja desktopowa, ale praca, którą śledzi, nie zatrzymuje się, gdy odchodzisz od biurka. Zdalne sterowanie paruje Twój telefon z Twoim cc_server, korzystając z aplikacji towarzyszącej Remote pod adresem remote.usectrl.dev, dzięki czemu możesz śledzić flotę stamtąd: czytać wiadomości i zgłoszenia, odpowiadać agentowi, przeglądać newsfeed — a dźwięk, transkrypcja, kod źródłowy ani poświadczenia znajdujące się na serwerze nigdy go nie opuszczają.

Traktuj ją jako towarzysza głównego widoku, nastawionego głównie na czytanie. Nie ma zastępować pełnego klienta desktopowego.

Transport

Telefon dociera do cc_server przez WebSocket: albo bezpośrednim połączeniem (loopback, LAN, tailnet lub wss://), albo przez pokój dostępny na zaproszenie w brokerze sygnalizacyjnym, który przekazuje zapieczętowane ramki. Nie ma kanału danych peer-to-peer.

Co potrafi telefon

Sparowany telefon dociera do niewielkiego, celowo wybranego wycinka powierzchni serwera:

Czytanie: zgłoszenia, agenci, przestrzenie oraz ich wiadomości i Twój newsfeed
Odpowiadanie: wysłanie wiadomości w przestrzeni, zaktualizowanie lub przypisanie zgłoszenia, oznaczenie artykułu jako przeczytanego lub zapisanego
Uruchamianie playbooka: utworzenie instancji zapisanego szablonu planu wraz z jego parametrami. To jedynie proponuje plan; nic się nie wykonuje ani nie wydaje środków, dopóki operator nie zatwierdzi go w Plan Studio w pełnym kliencie
Przełączanie obszarów roboczych z własnego selektora telefonu

To niemal wszystko. Telefon to podmiot o niższych uprawnieniach niż pełny klient. Nie może uruchamiać procesów, wydawać budżetu LLM, wypychać zmian do GitHub ani tworzyć obszarów roboczych. Zobacz model dostępu, aby dowiedzieć się, jak jest to wymuszane, a nie tylko zamierzone.

Jak powstaje połączenie

Połączenie opiera się na brokerskim przekaźniku: serwer dołącza jako właściciel do jednego pokoju dostępnego na zaproszenie w brokerze wss://, a każdy sparowany klient — desktop, web, telefon — dołącza do tego samego pokoju z tokenem dopuszczenia o ograniczonym czasie ważności. Składają się na to trzy elementy:

Element	Rola
Remote (aplikacja na telefon)	Aplikacja webowa towarzysząca, domyślnie hostowana pod `remote.usectrl.dev`, albo hostowana samodzielnie. Ładuje się w przeglądarce, przechowuje rekord parowania w IndexedDB.
Broker przekaźnika	Bezstanowy przekaźnik `wss://` (`cc_signaling_server`) hostujący pokoje N-kierunkowe. Przenosi wyłącznie nieprzezroczyste ramki: każdy ładunek jest szyfrowany end-to-end między telefonem a serwerem, więc broker nigdy nie widzi danych aplikacji ani sekretu parowania i nigdy nie interpretuje tego, co przekazuje.
`cc_server`	Właściciel pokoju. Odpowiada na wywołania telefonu przez ten sam dyspozytor, którego używa każdy inny klient.

Oferta parowania zawiera deskryptor połączenia wyliczający każdą ścieżkę do serwera (LAN, tailnet, publiczny wss://, przekaźnik) oraz odcisk tożsamości serwera. Resolver telefonu wybiera najlepszą osiągalną ścieżkę i przypina odcisk przy pierwszym połączeniu (TOFU); przekaźnik gwarantuje łączność nawet wtedy, gdy nie istnieje żadna bezpośrednia ścieżka, nie mogąc przy tym nigdy odczytać ruchu.

Czym jest ładunek parowania

Parowanie jest tworzone w aplikacji i dostarczane jako link bezpośredni; procedurę opisano w Sparuj urządzenie. Tutaj liczy się jego anatomia.

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

Ładunek jedzie we fragmencie adresu URL, czyli w części po #, której przeglądarki nigdy nie wysyłają do serwera, więc host HTTPS PWA nigdy go nie widzi. Zawiera wszystko, czego telefon potrzebuje, by dotrzeć do serwera i udowodnić, kim jest: deskryptor połączenia (wszystkie ścieżki plus odcisk tożsamości), świeżo utworzony identyfikator urządzenia, 32-bajtowy wstępnie współdzielony klucz oraz znacznik wygaśnięcia. Telefon dekoduje go, zapisuje lokalnie rekord parowania i usuwa fragment, aby sekret zniknął z adresu URL.

Istnieją dwa kształty ładunku i nie są wymienne. Kod QR dla telefonu tworzony w panelu parowania w aplikacji to opisany wyżej PairingPayload w wersji v2, wskazujący na host PWA Remote. cc_server pair --client-url emituje inny, starszy link v1 ({s, i, k} — adres URL serwera, identyfikator urządzenia, klucz), przeznaczony wyłącznie dla klienta webowego.

Różnią się też czasem życia, co łatwo pomylić:

Tworzone przez	Ważność poświadczenia
Panel parowania w aplikacji (`pairing.mint`)	30 dni, zawsze
`cc_server pair` w wierszu poleceń	Brak — poświadczenie nie wygasa

Model dostępu

Sparowane urządzenie jest uwierzytelnione, ale niezaufane. Kilka niezależnych bram nie pozwala, by zatwierdzone (lub ujawnione) parowanie stało się pełną kontrolą nad serwerem.

1. Granicą jest członkostwo, a nie parowanie

Ważny klucz parowania dowodzi, którym urządzeniem jesteś. O tym, co możesz czytać lub zmieniać, decyduje Twoja rola w obszarze roboczym, rozstrzygana na nowo przy każdym wywołaniu, a w przypadku wszystkiego, co ujawnia zawartość repozytorium — uprawnienia do poszczególnych repozytoriów. Urządzenie dysponujące zupełnie dobrym kluczem, ale należące do użytkownika, który nie jest członkiem wskazanego obszaru roboczego, zostaje odrzucone komunikatem „Not a member of this workspace”.

Minimalny poziom roli wynika z rodzaju operacji, chyba że operacja deklaruje własny: odczyty wymagają guest, mutacje wymagają member, operacje destrukcyjne wymagają admin.

2. Telefon to niższy poziom sesji

Poza kontrolą roli sesja telefonu ma niższe uprawnienia niż sesja desktopowa lub webowa. Operacje zadeklarowane jako przeznaczone wyłącznie dla pełnego klienta są odrzucane dla telefonu, zanim uruchomi się procedura obsługi, niezależnie od tego, jak uprzywilejowany jest stojący za nim użytkownik: tworzenie, listowanie, zmienianie nazw i unieważnianie parowań urządzeń; odczytywanie i ustawianie łączności tunelu; kopia zapasowa serwera oraz eksport i import obszaru roboczego; wykrywanie i zabijanie procesów; sondy adapterów; ustawienia serwera; administracja SSO; sterowanie flotą; oraz przejmowanie i oddawanie działającego agenta.

3. Lista dozwolonych narzędzi z domyślnym zakazem

Jeśli chodzi konkretnie o powierzchnię narzędzi MCP (tools/call), o tym, które narzędzia telefon może wywoływać, decyduje lista dozwolonych z domyślnym zakazem. Wszystko, czego na niej nie ma, jest odrzucane, zanim zostanie uruchomione. Lista nastawiona jest na czytanie i obserwację, plus garść zapisów wyłącznie lokalnych — wiadomość, aktualizacja zgłoszenia, oznaczenie artykułu — które nie wydają budżetu LLM, nie uruchamiają procesu i nie dotykają żadnego systemu zewnętrznego.

Zabronione są na przykład: konsultowanie agenta, rozpoczynanie recenzji AI, zabijanie agenta, publikowanie recenzji do GitHub, zatrudnianie i zwalnianie agentów, tworzenie obszaru roboczego.

4. Zakres obszaru roboczego ustalany przy każdym wywołaniu

Serwer nie przechowuje „bieżącego obszaru roboczego”. Jest bezstanowy z założenia: każde wywołanie ograniczone do obszaru roboczego musi w swoich argumentach wskazać docelowy workspace_id, a dyspozytor odrzuca wywołanie od razu, gdy go brakuje albo gdy wskazuje obszar roboczy niezarejestrowany na serwerze — zanim cokolwiek otworzy bazę danych. Telefon nie może więc nigdy odziedziczyć zakresu innego klienta ani w niego „przepłynąć”, a wskazanie obcego obszaru roboczego też nie pomaga, bo nadal obowiązuje kontrola członkostwa z bramy 1. To ten sam niezmiennik izolacji obszarów roboczych, którego egzekwuje reszta produktu.

5. Ramki szyfrowane end-to-end kluczem wstępnie współdzielonym

Każda ramka między telefonem a serwerem jest zapieczętowana kluczem parowania; token dopuszczenia jedynie wpuszcza klienta do pokoju, niczego nie odszyfrowuje. Broker przekazuje szyfrogram i nigdy nie widzi klucza. Urządzenie, które zostało unieważnione, zastaje swoje poświadczenie już usunięte, więc przy ponownym połączeniu odmawia domyślnie.

Poświadczenie utworzone przez aplikację ma ważność ograniczoną do 30 dni; po tym czasie brama połączenia je odrzuca i telefon musi sparować się ponownie. Unieważnianie działa na bieżąco: serwer obserwuje tabelę urządzeń i w ciągu kilku sekund zrywa otwarte sesje unieważnionego urządzenia, zamiast czekać na jego kolejne połączenie.

6. Ograniczanie tempa na podmiot

Ogranicznik z przesuwnym oknem ogranicza zdalny ruch narzędziowy do 120 wywołań na minutę, z ciaśniejszym podlimitem 30 na minutę dla czasowników mutujących. Budżet należy do podmiotu, a nie do sesji: trzy Twoje urządzenia czerpią z jednego przydziału, więc przejęty klient nie może kupić sobie zapasu, otwierając więcej sesji, a jeden hałaśliwy członek nie może zagłodzić pozostałych.

7. Broker, który niczego się nie dowiaduje

Broker przekaźnika jest celowo głupi: hostuje pokoje, przekazuje zapieczętowane ramki i nie przechowuje żadnych kont, danych aplikacji ani kluczy. Pokoje są dostępne na zaproszenie i tymczasowe. Dane aplikacji, dźwięk, transkrypcja, kod źródłowy i poświadczenia pozostają na serwerze.

Aktualizacje na żywo

Po sparowaniu telefon otrzymuje aktualizacje na żywo w postaci ramek powiadomień — nowe wiadomości agentów, przypisane do Ciebie zgłoszenia, zmiany statusu — odzwierciedlające powiadomienia samego desktopu. Serwer rozgłasza te ramki do każdej połączonej sesji, a filtr obszaru roboczego jest stosowany po stronie klienta, więc to, co widzisz, jest ograniczone do obszaru roboczego, na który patrzysz.

Gdzie to znajdziesz

Miejsce	Co pokazuje
Ustawienia → Ty → Twoje urządzenia (`/workspaces/:workspaceId/settings/you/devices`)	Sparowani klienci z bieżącym statusem oraz Sparuj nowego klienta (przeglądarka, aplikacja desktopowa lub telefon) i unieważnianie

Ten sam panel tworzy parowania dla drugiej przeglądarki lub aplikacji desktopowej, nie tylko telefonów — przepływ jest identyczny, różni się wyłącznie link bezpośredni.

Zobacz też

Obszary robocze i izolacja: zakres ustalany przy każdym wywołaniu, na którym się to opiera
Wieloosobowość — tożsamość, członkostwo i obecność: role, członkostwo i uprawnienia do repozytoriów
Wdrażanie i klienci: gdzie zdalne sterowanie plasuje się wśród poziomów klientów
Architektura: gdzie zdalne sterowanie plasuje się w stosie
Sparuj urządzenie