Технический контекст
Я люблю такие треды за приземленность: человеку не нужен красивый концепт, ему нужно прямо сейчас показать Claude несколько terminal stdout одновременно. И вот тут идея с отдельным MCP звучит модно, но на практике я бы тоже первым делом смотрел в сторону tmux.
Для AI automation это вообще очень нормальный паттерн. Я поднимаю одну tmux-сессию, раскладываю процессы по pane, а дальше уже решаю, что именно отдавать модели: живой поток, снапшот экрана или лог-файл.
Сам tmux, конечно, не является MCP и сам по себе не умеет «магически» объединять все выводы в удобный канал для LLM. Но у него есть то, что реально важно: параллельные терминалы, стабильные long-running сессии и команды вроде capture-pane и pipe-pane, через которые можно вытащить stdout наружу.
Если задача простая, я бы делал так: несколько pane в одной сессии, на каждом процессе свой вывод, затем либо 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 так, чтобы оно экономило часы команде, а не добавляло еще один хрупкий слой поверх инфраструктуры.