Технічний контекст
Я люблю такі обговорення за практичність: людині не потрібен красивий концепт, їй потрібно прямо зараз показати Claude кілька terminal stdout одночасно. І тут ідея з окремим MCP звучить модно, але на практиці я б теж насамперед дивився в бік tmux.
Для AI automation це взагалі дуже нормальний патерн. Я піднімаю одну tmux-сесію, розкладаю процеси по панелях (pane), а далі вже вирішую, що саме віддавати моделі: живий потік, знімок екрана чи лог-файл.
Сам tmux, звісно, не є MCP і сам по собі не вміє «магічно» об'єднувати всі виводи у зручний канал для LLM. Але в нього є те, що справді важливо: паралельні термінали, стабільні long-running сесії та команди на кшталт capture-pane і pipe-pane, через які можна витягнути stdout назовні.
Якщо завдання просте, я б робив так: кілька панелей в одній сесії, на кожному процесі свій вивід, потім або tmux capture-pane -p для періодичного знімка, або tmux pipe-pane для запису потоку у файл. Вже цей файл або агрегований stdout легко передати в Claude, у свій скрипт або в прошарок для AI integration.
Зі згаданим terminalcp mcp я був би обережним. За відкритими джерелами, це не схоже на стандартний, широко підтверджений інструмент, тож я б не будував на ньому архітектуру, поки сам не перевірю руками. Для інтерактивних CLI-штук може виявитися корисною локальною знахідкою, але tmux тут виглядає як надійніша база.
Що це змінює для бізнесу та автоматизації
Найбільш очевидний плюс: не потрібно городити окремий складний прошарок там, де вистачить термінального мультиплексора та пари shell-скриптів. Це здешевлює AI implementation для внутрішніх агентів, які стежать за логами, деплоями, тестами або batch-завданнями.
Виграють команди, яким потрібен швидкий прототип або робочий internal tool вже сьогодні. Програють ті, хто намагається відразу вигадати «ідеальну платформу» і витрачає тиждень на абстракції замість того, щоб за вечір зібрати робочий контур.
Але є й межа: щойно вам знадобляться нормальні права доступу, аудит, маршрутизація потоків, фільтрація секретів і стійкість до збоїв, одного tmux вже замало. Ми в Nahornyi AI Lab якраз закриваємо такі переходи від кустарної схеми до нормальної automation with AI, щоб агент бачив потрібний контекст, а бізнес не ловив хаос у проді.
Якщо у вас Claude, OpenAI або локальна модель вже впираються в термінали, логи та CLI-утиліти, можна не винаходити зайвого. Я б спочатку подивився на ваш поточний workflow і разом з Nahornyi AI Lab зібрав AI solution development так, щоб воно економило години команді, а не додавало ще один крихкий шар поверх інфраструктури.