# GitHub Copilot отримав Computer Use: агент тепер може натискати кнопки

> Copilot CLI і app отримали computer use для desktop-застосунків (public preview, macOS і Windows). Розбираємо use cases, модель approvals, ієрархію інтерфейсів і ризики GUI-автоматизації.

- Автор: Юра Скиба (https://cookiesoftware.io)
- Опубліковано: 2026-10-15
- Категорія: AI в роботі розробника
- Canonical: https://cookiesoftware.io/blog/github-copilot-computer-use

---

Computer use у GitHub Copilot – це public preview на macOS і Windows для Copilot CLI та Copilot app: агент може читати вміст desktop-застосунків через accessibility tree або скриншоти, клікати, вводити текст і переносити дані між програмами. Перед керуванням кожним застосунком потрібен approval користувача. Це закриває «останню милю» автоматизації там, де немає API, – але GUI був і лишається найменш надійним інтерфейсом, тож місце computer use – в кінці ієрархії, а не на її початку.

## Що саме з'явилось

Агент уже давно вміє писати код, запускати тести й створювати PR. Тепер GitHub дав йому руки: computer use дозволяє Copilot взаємодіяти з desktop-застосунками – «натискати елементи керування, вводити й редагувати текст, тиснути клавіші, скролити й перетягувати, вести workflow через кілька застосунків» (формулювання з документації).

Технічно агент «бачить» застосунок двома способами: через accessibility tree операційної системи або через скриншоти. Перший – структурований і надійніший, другий – універсальний fallback для нестандартних UI.

Статус чесно позначений: public preview, subject to change. Linux поки не підтримується.

## Навіщо GUI, коли є API?

Тому що API є не всюди.

У компаніях досі живуть internal admin panels, desktop tools, legacy CRM, vendor software і тестові середовища без нормального API. Саме там agent workflow раніше закінчувався фразою «тепер вручну відкрий застосунок і натисни...».

Computer use закриває цю останню милю. Але важливо тримати в голові правильну ієрархію інтерфейсів:

**API/CLI > structured tool > browser automation > raw computer use.**

Computer use потрібен не тому, що він найкращий, а тому, що іноді іншого інтерфейсу просто немає. Якщо в задачі є API – використовуй API. Побудований на скриншотах workflow – це технічний борг із дня створення.

## Як працюють approvals

Модель дозволів тут продуманіша, ніж можна очікувати від preview:

- **Per-app approval.** Перед першою взаємодією з застосунком агент питає дозвіл. Варіанти: дозволити лише на цю сесію, «Always allow» (зберігається локально і діє одразу для CLI та app на цій машині) або відмовити.
- **Deny переважає.** Правила, що забороняють інструмент, мають пріоритет над автоматичними чи збереженими дозволами – тобто заборону не можна випадково «перезаписати» зручністю.
- **Enterprise-контроль.** Адміністратори можуть вимкнути computer use повністю на рівні організації.

Це та сама логіка, що й у [локальному sandboxing для Copilot](/blog/copilot-local-sandbox-ollama): prompt – це побажання, permission – це enforcement.

## Але GUI – найменш надійний інтерфейс

Документація GitHub сама чесно перелічує проблеми: агент «може обрати не той елемент керування, ввести текст не туди або мати труднощі з нестандартними чи динамічними контролами». Додай сюди чутливість до таймінгу – діалог відкрився пізніше, ніж агент очікував, – і отримаєш клас збоїв, якого не буває в API-інтеграцій:

- кнопка змінила позицію після оновлення застосунку – workflow зламався;
- A/B-тест показав інший layout – агент бачить іншу картинку;
- модальне вікно з'явилось із затримкою – агент клікнув у порожнечу.

І найважливіше попередження з доків: неоднозначні інструкції або неочікуваний вміст екрана можуть призвести до **ненавмисних дій, що зачіпають пристрій, дані або підключені акаунти**. Плюс окремий нюанс приватності: вікна застосунків можуть показувати чутливу інформацію – зокрема про інших людей.

## Security: це вже privileged automation

AI, який бачить desktop і може клікати, – це не autocomplete. Правила для такого агента ті самі, що для будь-якої привілейованої автоматизації:

1. **Narrow permissions** – дозволяй лише конкретні застосунки, а не «все підряд через Always allow».
2. **Confirmation для destructive actions** – будь-яка дія з «Delete», відправленням чи оплатою має вимагати людину.
3. **Isolated environment де можливо** – [досвід Vercel Sandbox Challenge](/blog/vercel-sandbox-million-dollar-challenge) добре показує, що ізоляція – це implementation, а не слово.
4. **Audit trail** – що агент натискав і коли.
5. **Timeout і safe fallback** – завислий GUI-workflow не має висіти вічно.

І загальне правило з [чекліста перевірки AI-коду](/blog/ai-kod-chek-list-perevirky) працює й тут: не делегуй агенту дію, наслідки якої не зможеш швидко відкотити.

## Як не перетворити агента на хаос із мишкою

1. **Computer use як перший вибір.** Є API – використовуй API. GUI-автоматизація як default – це добровільний flaky-шар у процесі.
2. **«Always allow» на все.** Зручно сьогодні, боляче в день, коли агент отримає неоднозначну інструкцію поруч із відкритим банківським застосунком.
3. **Відсутність людини на незворотних кроках.** Прев'ю-технологія + незворотна дія – погане поєднання.
4. **Ігнорування приватності екрана.** Якщо на desktop відкриті чужі дані, агент їх теж «бачить».
5. **Жодного плану на збій.** GUI-workflow ламаються тихо; без audit trail ти дізнаєшся про це від користувачів.

## Знайди свою «останню милю»

Знайди у своїй команді один процес, який досі закінчується словами «а далі вручну відкрий X і натисни Y». Випиши: (1) чи є в X хоч якийсь API або CLI; (2) що станеться, якщо агент клікне не туди; (3) яка дія в цьому процесі незворотна. Якщо API немає, а незворотних дій нема або вони захищені confirmation – це кандидат на computer use. Якщо API є – ти щойно знайшов собі нормальну інтеграцію замість скриншотного workflow.

Computer use – корисний інструмент для чесно обмеженого класу задач. Головне не переплутати «нарешті можна» з «тепер треба всюди».