Codex na macOS: steruj dowolną aplikacją kursorem i klawiaturą

Gdy pierwszy raz zobaczyłem zapowiedź OpenAI z 16 kwietnia 2026, zatrzymałem się na jednym zdaniu: „Codex może teraz używać dowolnej aplikacji na macOS, widząc ekran, klikając i pisząc własnym kursorem”. Brzmi prosto, ale konsekwencje są spore. W naszej pracy w Marketing-Ekspercki często wdrażamy automatyzacje w make.com i n8n, a jednak co chwilę trafiamy na mur: aplikacja nie ma API, integracja jest kula w płot, a eksport danych wymaga „przeklikania się” przez interfejs. I tu właśnie wchodzi podejście „computer use” — czyli sterowanie aplikacjami tak, jak robi to człowiek: myszką i klawiaturą.

OpenAI pisze też, że narzędzie działa w tle i nie przejmuje komputera. To ważne, bo większość osób ma złe skojarzenia z botami RPA, które „okupują” maszynę, przerywają pracę i każą się nie ruszać. Jeśli deklaracja pokrywa się z praktyką, to dostajemy ciekawą opcję do zadań typu: testy aplikacji, iteracje frontendu, albo dowolny proces, którego nie da się sensownie spiąć przez API.

W tym artykule opisuję, co oznacza „computer use on macOS” w kontekście Codex, do czego realnie może się przydać i jak ty możesz o tym myśleć w marketingu, sprzedaży oraz automatyzacjach (zwłaszcza wtedy, gdy make.com i n8n dochodzą do ściany). Trzymam się tego, co wynika z komunikatu OpenAI, a tam, gdzie wchodzimy w scenariusze użycia, zaznaczam logikę i ograniczenia.

Co OpenAI ogłosiło: „computer use on macOS” w skrócie

Źródłem jest wpis OpenAI na X z 16 kwietnia 2026. Treść komunikatu sprowadza się do trzech punktów:

• Codex potrafi używać dowolnej aplikacji na macOS, bo „widzi” ekran i wykonuje akcje myszką oraz klawiaturą.
• Ma własny kursor (czyli operuje w ramach osobnej sesji/warstwy sterowania).
• Działa w tle i nie przejmuje komputera, co sugeruje, że równolegle możesz pracować.

Dodatkowo OpenAI podaje przykłady zastosowań: frontend iteration, app testing oraz „dowolny workflow, który nie udostępnia API”. I to ostatnie jest w praktyce najciekawsze, bo w firmach takich jak nasza aż roi się od „workflowów bez API”.

Dlaczego to zmienia sposób myślenia o automatyzacjach

Do tej pory mieliśmy dwa dominujące podejścia:

• Integracje po API (make.com, n8n, webhooki, konektory) — szybkie, stabilne, skalowalne, o ile API istnieje i ma sensowny zakres.
• RPA (roboty klikające w interfejs) — często kruche, zależne od układu ekranu, podatne na drobne zmiany w UI.

„Computer use” od Codex, w samym założeniu, jest bliżej RPA, ale dochodzi tu element, którego klasyczne RPA często nie miało w wygodnej formie: model, który rozumie kontekst (co widzi) i potrafi dopasować działanie do sytuacji, zamiast ślepo odtwarzać nagraną sekwencję kliknięć.

Ja to sobie upraszczam tak: API to autostrada, UI to drogi lokalne. Make i n8n świetnie jadą autostradą. Codex z „computer use” sugeruje: „OK, to ja pojadę drogami lokalnymi, nawet jak nie ma zjazdu”. Nie ma róży bez kolców — UI potrafi się zmieniać — ale sam kierunek jest bardzo praktyczny.

Jak działa sterowanie aplikacją „widząc, klikając i pisząc”

OpenAI nie podaje w tym krótkim komunikacie architektury ani detali implementacyjnych, więc nie będę udawał, że znam techniczne wnętrzności. Mogę natomiast opisać sens funkcjonalny, bo on jest dość czytelny:

• Model dostaje obraz interfejsu (to, co jest na ekranie).
• Wybiera akcję: ruch kursora, klik, wpisanie tekstu, ewentualnie skróty klawiaturowe.
• Wykonuje serię kroków, aż do osiągnięcia celu: np. kliknięcie przycisku, wypełnienie formularza, uruchomienie testu.

Różnica w porównaniu do „zwykłej” automatyzacji polega na tym, że tutaj nie potrzebujesz endpointu API. Potrzebujesz natomiast stabilnego interfejsu, sensownych uprawnień systemowych (macOS i dostępność/Accessibility to temat rzeka) oraz dobrego opisu zadania.

Własny kursor i praca w tle

Wpis OpenAI podkreśla własny kursor i działanie w tle. To brzmi jak rozwiązanie, które nie wchodzi ci na ekran i nie „macha myszką” pod ręką, tylko pracuje w odseparowanym środowisku. Jeśli tak jest, to spada jeden z największych problemów dawnych robotów: „nie dotykaj komputera, bo robot się pogubi”.

Dla mnie — jako osoby, która często prowadzi jednocześnie rozmowy, sprawdza kampanie i dogląda automatyzacji — to może być różnica między „fajny bajer” a „narzędzie, którego faktycznie używam”.

Najlepsze zastosowania: kiedy UI ma sens, a kiedy nie

W praktyce warto podejść do tego pragmatycznie. Sterowanie UI bywa świetne, gdy:

• aplikacja nie ma API albo ma je szczątkowe,
• dany proces występuje rzadko, ale jest upierdliwy,
• koszt ręcznego klikania jest wysoki (czas, błędy),
• zmiana procesu na „prawdziwą integrację” trwałaby tygodniami.

Natomiast UI bywa kiepskie, gdy:

• proces dzieje się tysiące razy dziennie,
• interfejs zmienia się często albo jest zależny od wielu stanów,
• masz do przetworzenia wrażliwe dane i potrzebujesz twardej kontroli audytowej,
• zadanie wymaga dużej precyzji i przewidywalności na poziomie „co do piksela”.

Ja zwykle mówię klientom: jeśli API istnieje, zaczynamy od API. Jeśli go nie ma — wtedy rozważamy warstwę UI, ale z planem B i z sensownymi zabezpieczeniami.

Przykłady użycia, które pasują do marketingu i sprzedaży

OpenAI rzuca hasła typu testy i iteracje frontendu, ale w firmach takich jak nasza szybko pojawiają się też przyziemne scenariusze: raporty, aktualizacje, przenoszenie danych, publikacje. Poniżej kilka przykładów, które brzmią bardzo „życiowo”.

1) Aktualizacja treści na stronie w panelu bez API

Masz panel CMS, w którym redaktor musi wkleić opis produktu, ustawić meta title, dodać grafikę i opublikować. To klasyczna robota „klikologią”. Jeśli Codex na macOS potrafi to zrobić na podstawie widoku ekranu, ty możesz przygotować treść i polecić wykonanie serii czynności.

W praktyce widzę tu dwa realne tryby pracy:

• Tryb półautomatyczny: Codex wykonuje kroki, a ty zatwierdzasz publikację.
• Tryb nocny: Codex robi aktualizacje po godzinach, a rano dostajesz raport z wykonania.

2) Wklepywanie leadów do narzędzia, które „nie gada” z resztą świata

W 2026 nadal istnieją systemy, które wyglądają jak relikt i nie mają sensownej integracji. Zdarza się, że klient ma wewnętrzny CRM albo aplikację branżową, gdzie leady muszą się znaleźć, bo inaczej handlowcy nie ruszą.

Jeśli nie zrobisz integracji po API, zostaje człowiek. A jeśli zostaje człowiek, to wcześniej czy później zaczyna się festiwal: literówki, opóźnienia, „zapomniałem”. UI-sterowanie może domknąć temat, chociaż nadal trzeba mądrze rozwiązać kwestię danych i uprawnień.

3) Zbieranie danych z paneli reklamowych i narzędzi analitycznych

Wiem, wiem — większość dużych platform ma API. Tylko że czasem potrzebujesz danych z miejsca, które API ma, ale raportu już nie. Albo masz dostęp przez konto klienta i ograniczone możliwości. Albo chcesz wyciągnąć zrzut/eksport, bo tak życzy sobie dział finansowy.

Wtedy Codex mógłby:

• wejść do panelu,
• ustawić zakres dat,
• wyeksportować CSV,
• zapisać plik w określonym folderze.

A później make.com albo n8n może przejąć temat: wczytać plik, przeliczyć dane, wysłać raport e-mailem czy na Slacka. Taki podział pracy jest dla mnie naturalny: UI do pozyskania danych, automatyzacja do obróbki i dystrybucji.

4) Testowanie zmian na froncie (zgodnie z przykładem OpenAI)

Frontend iteration brzmi jak codzienność zespołów produktowych: poprawka w UI, szybkie sprawdzenie, czy CTA działa, czy formularz się wysyła, czy koszyk się nie wysypał.

Jeżeli Codex potrafi seriami klikać, wypełniać formularze i sprawdzać stany, to może odciążyć QA w prostych, powtarzalnych testach. I z mojego doświadczenia: to są właśnie te testy, które ludzie odkładają „na później”, bo są nudne jak flaki z olejem.

Jak to połączyć z make.com i n8n w realnym procesie

Najciekawsze rzeczy rzadko powstają w jednym narzędziu. U nas typowy układ wygląda tak:

• make.com / n8n steruje logiką procesu (kiedy uruchomić zadanie, skąd wziąć dane, gdzie je wysłać),
• warstwa „computer use” wykonuje czynności w aplikacji, gdy nie ma API,
• na końcu automatyzacja zbiera rezultaty: pliki, potwierdzenia, statusy.

Przykładowy scenariusz: eksport raportu i wysyłka do klienta

• n8n odpala proces o 7:00 w poniedziałek.
• Codex na macOS otwiera aplikację/panel web, ustawia filtry i robi eksport.
• Plik ląduje w określonym folderze (np. „Raporty/Klient_X”).
• n8n wykrywa nowy plik, wstawia dane do arkusza, generuje PDF i wysyła e-mail.

To jest przykład „z życia”, bo dokładnie takie rzeczy ludzie robią ręcznie. A potem mówią, że „nie ma czasu na strategię”. No jasne, skoro pół poranka idzie na klikanie eksportów.

Ograniczenia i ryzyka, które warto znać przed wdrożeniem

Żeby nie było zbyt słodko: sterowanie interfejsem ma wbudowane ryzyka. Ja bym zwrócił uwagę na cztery obszary.

1) Zmienność interfejsu

Wystarczy, że aplikacja przesunie przycisk, zmieni nazewnictwo albo doda popup i automatyzacja potrafi się wysypać. Da się to łagodzić (np. przez obsługę wyjątków, kroki weryfikacji), ale problem istnieje.

2) Uprawnienia i bezpieczeństwo na macOS

macOS dość restrykcyjnie podchodzi do sterowania komputerem przez inne aplikacje. Pojawiają się uprawnienia typu Accessibility, nagrywanie ekranu, dostęp do plików. To dobrze, bo system cię chroni, ale dla automatyzacji oznacza to dodatkowe kroki wdrożeniowe.

Jeśli masz w firmie polityki bezpieczeństwa (a coraz częściej są), wdrożenie będzie wymagało uzgodnień. Lepiej to powiedzieć wprost, niż udawać, że „się samo zrobi”.

3) Dane wrażliwe i zgodność z regulacjami

Jeżeli proces dotyczy danych klientów, finansów, zdrowia czy czegokolwiek regulowanego, nie podchodź do tego na zasadzie „a jakoś to będzie”. Potrzebujesz jasnej odpowiedzi: co jest widoczne na ekranie, gdzie trafiają dane, jak wygląda logowanie, jak realizujesz audyt i kontrolę dostępu.

W Marketing-Ekspercki zwykle zaczynamy od mapy danych: co wchodzi, co wychodzi, kto ma dostęp, gdzie to się zapisuje. To nudny etap, ale ratuje skórę.

4) Powtarzalność i testowanie procesu

UI automatyzujesz dobrze wtedy, gdy proces jest stabilny. Jeśli za każdym razem wygląda inaczej, model będzie musiał „improwizować”, a ty będziesz gasić pożary. A pożary w automatyzacji nie są romantyczne, tylko kosztowne.

SEO i treści: co to oznacza dla marketerów praktycznie

Z perspektywy marketingu ja widzę dwa kierunki:

• Przyspieszenie produkcji i publikacji w miejscach, gdzie nie masz integracji (np. niszowe CMS-y, zewnętrzne portale, panele partnerów).
• Lepsza kontrola jakości przez automatyzację testów: formularze, linki, renderowanie, podstawowe check-listy przed publikacją.

To nie oznacza, że nagle „wszystko się samo zrobi”. Ale oznacza, że możesz oddelegować powtarzalne kawałki, a sobie zostawić decyzje, które faktycznie wymagają głowy: przekaz, oferta, struktura landing page’a, argumentacja.

Jak przygotować proces, żeby Codex (i ty) się nie męczyliście

Jeśli myślisz o wykorzystaniu sterowania UI, ułatwisz sobie życie kilkoma zasadami. U nas to działa zaskakująco dobrze, bo jest proste.

1) Spisz instrukcję jak dla nowej osoby w zespole

Nie chodzi o poemat. Chodzi o krótką, jasną sekwencję kroków: gdzie wejść, co kliknąć, co wpisać, jak zapisać wynik. Jeśli ty nie umiesz tego opisać, model też będzie miał pod górkę. Proste jak drut.

2) Zadbaj o przewidywalne nazwy plików i folderów

Automatyzacje kochają porządek. Ustal schemat nazw, np. „Raport_KlientX_2026-04-16.csv”. Wtedy n8n/make.com łatwo to przechwyci i przetworzy.

3) Dodaj kroki kontroli

Ja lubię wstawiać „checkpointy”:

• sprawdź, czy na ekranie widać właściwe konto,
• potwierdź zakres dat,
• zweryfikuj, czy eksport ma sensowny rozmiar (np. nie 0 KB).

To drobiazgi, ale ratują przed klasycznym błędem: „robot zrobił, tylko że nie to”.

Co dalej: jak podejść do wdrożenia w firmie

Jeśli chcesz to sprawdzić u siebie, ja bym poszedł taką ścieżką:

• Krok 1: wybierz jeden proces, który dziś robisz ręcznie i który ma jasny początek oraz koniec.
• Krok 2: oceń ryzyko danych (czy to wrażliwe rzeczy, czy raczej publiczne raporty).
• Krok 3: przygotuj środowisko (konto testowe, oddzielny profil, uporządkowane foldery).
• Krok 4: połącz rezultat z make.com lub n8n (np. plik w folderze uruchamia dalsze kroki).
• Krok 5: dopiero potem myśl o skali.

Nie ma co brać się od razu za „automatyzację całej firmy”, bo to zwykle kończy się tym, że wszyscy się frustrują. Lepiej wyjść na swoje małymi zwycięstwami.

Najczęstsze pytania, które słyszę w takich tematach

Czy to zastąpi integracje w make.com i n8n?

Raczej nie. Ja traktuję to jako uzupełnienie, gdy nie ma API albo gdy integracja jest nieopłacalna. Make i n8n nadal wygrywają w stabilności, kontroli i logice procesów.

Czy to działa „na każdej aplikacji”?

Tak brzmi deklaracja w komunikacie („any app”), ale w praktyce zawsze pojawiają się ograniczenia: uprawnienia, zabezpieczenia aplikacji, nietypowe UI, okna modalne, CAPTCHA i tak dalej. Dlatego ja zakładam: działa w wielu przypadkach, ale wymaga testów.

Czy to bezpieczne?

Bezpieczeństwo zależy od tego, jak to wdrożysz: kto ma dostęp, gdzie trafiają dane, jak wygląda kontrola. Sam mechanizm „klikania” nie jest ani bezpieczny, ani niebezpieczny — to narzędzie. Cała reszta to proces i higiena.

Co ja bym zrobił na twoim miejscu (taki uczciwy plan minimum)

Gdybyś przyszedł do mnie i powiedział: „chcę sprawdzić Codex na macOS do obsługi aplikacji bez API”, zaproponowałbym mały pilotaż:

• jedno zadanie: np. eksport raportu raz w tygodniu,
• jasne kryterium sukcesu: poprawny plik w folderze do 5 minut,
• log działania: co się udało, co przerwało proces, jaki był powód,
• połączenie z n8n/make: wysyłka raportu i archiwizacja.

Po tygodniu masz odpowiedź, czy to ma sens, czy to tylko ciekawostka. I co ważne: nie spalisz pół miesiąca na budowę czegoś, co okaże się chimeryczne.

Jeśli chcesz, podeślij mi (choćby ogólnie) jaki proces bez API najbardziej cię męczy: raportowanie, wklepywanie danych, testowanie, publikacje. Ja dopasuję do tego szkic automatyzacji i powiem, gdzie make.com/n8n kończy możliwości, a gdzie warstwa sterowania UI może realnie pomóc.

Źródło: https://x.com/OpenAI/status/2044827932145897652