Обновление и удаление

Обновление

Профили, .env, сессии, skills и cron лежат в VIBEOS_HOME (по умолчанию ~/.vibeos). Обновление меняет код приложения / бинарник Desktop и не сносит этот каталог.

Выберите путь под свой тип установки

Тип установки	Проверка	Установка
Git / install.sh / исходники	vibeos update --check или Desktop О программе → Проверить	vibeos update или Обновить
Packaged Desktop (DMG / NSIS с vibeos.com.ru/download)	О программе → Проверить + фоновый poll CDN latest.json (toast; без silent install)	Обновить скачивает установщик (проверка sha512, если есть в feed), открывает из Downloads/VibeOS-Updates/; данные в ~/.vibeos не трогаются
Android (Termux)	vibeos update --check (git + опциональная подсказка CDN Desktop)	только vibeos update — APK нет; не ставьте .exe / .dmg на телефон. См. Termux.
Homebrew / Nix	менеджер пакетов	brew upgrade vibeos-agent / nixos-rebuild (self-update отключён)
Docker	тег образа	docker pull … (внутри контейнера vibeos update запрещён)
Мессенджеры	—	/update (только git; managed — команда пакетного менеджера)

Git / исходники

Обновитесь одной командой:

vibeos update

Команда тянет origin/main репозитория VibeOS, обновляет зависимости и предлагает настроить новые параметры, добавленные после вашего последнего обновления.

подсказка

vibeos update автоматически обнаруживает новые параметры конфигурации и предлагает их добавить. Если вы пропустили это предложение, вы можете вручную выполнить vibeos config check, чтобы увидеть отсутствующие параметры, а затем vibeos config migrate, чтобы добавить их в интерактивном режиме.

Что происходит во время обновления

При выполнении vibeos update происходят следующие шаги:

1. Снимок данных спаривания — сохраняется облегчённый снимок состояния до обновления (охватывает ~/.vibeos/pairing/, правила комментариев Feishu и другие файлы состояния, изменяемые во время выполнения). Восстанавливается через процедуру восстановления снимков, описанную в разделе Снимки и откат, или путём извлечения последнего zip-архива быстрого снимка, который VibeOS сохраняет рядом с вашим каталогом ~/.vibeos/.
2. Git pull — загружает последний код из ветки main и обновляет подмодули
3. Проверка синтаксиса после pull + автоматический откат — после загрузки VibeOS компилирует восемь критических файлов, которые импортируются при каждом запуске vibeos. Если какой-либо из них не удаётся разобрать (например, оставшийся маркер конфликта слияния, случайно усечённый файл), VibeOS выполняет git reset --hard <sha-до-pull>, чтобы откатить установку, и ваша оболочка остаётся работоспособной. Повторно выполните vibeos update после исправления проблемы в upstream.
4. Установка зависимостей — выполняет uv pip install -e ".[all]" для установки новых или изменённых зависимостей
5. Миграция конфигурации — обнаруживает новые параметры конфигурации, добавленные с вашей версии, и предлагает их настроить
6. Автоматический перезапуск шлюзов — работающие шлюзы обновляются после завершения обновления, чтобы новый код вступил в силу немедленно. Шлюзы, управляемые службами (systemd на Linux, launchd на macOS), перезапускаются через менеджер служб. Ручные шлюзы перезапускаются автоматически, когда VibeOS может сопоставить работающий PID с профилем.

Обновление с нестандартной веткой: --branch

По умолчанию vibeos update отслеживает origin/main. Укажите --branch <имя>, чтобы обновиться с другой ветки — полезно для каналов контроля качества, функциональных веток или тестирования кандидатов в релизы:

vibeos update --branch release-candidate
vibeos update --check --branch experimental   # только предварительный просмотр отставания

Если ваш локальный checkout находится на другой ветке, VibeOS автоматически прячет незафиксированные изменения, переключает HEAD на целевую ветку и затем выполняет pull. Ветки, которые не существуют локально, автоматически отслеживаются из origin/<имя> (git checkout -B <имя> origin/<имя>). Ветки, которые не существуют нигде, завершаются с ошибкой — ваши спрятанные изменения восстанавливаются перед выходом, чтобы вы не остались в странном состоянии. Логика синхронизации форка только для main автоматически пропускается на ветках, отличных от main.

Локальные изменения при неинтерактивных обновлениях

Когда вы запускаете vibeos update в терминале, VibeOS прячет любые незафиксированные изменения в дереве исходного кода, выполняет pull, а затем спрашивает, нужно ли их восстановить — именно так, как и всегда. Для интерактивных обновлений ничего не меняется.

Когда обновление запускается без терминала — через кнопку «Обновить» в настольном/чат-приложении или обновление, инициированное шлюзом — запроса на ответ нет. Параметр updates.non_interactive_local_changes определяет, что произойдёт с вашими спрятанными изменениями:

# ~/.vibeos/config.yaml
updates:
  non_interactive_local_changes: stash   # по умолчанию: сохранить + авто-восстановление
  # non_interactive_local_changes: discard  # отбросить локальные изменения исходного кода

• stash (по умолчанию) — автоматически прячет, выполняет pull, затем автоматически восстанавливает ваши изменения поверх обновлённого кода. Ничего не теряется; если при восстановлении возникают конфликты, они сохраняются в git stash для ручного восстановления.
• discard — автоматически прячет и удаляет stash после pull, так что обновление всегда выполняется на чистом дереве. Используйте это только на машинах, где вы никогда не планируете хранить локальные изменения исходного кода VibeOS. При этом выполняется stash-drop (не git reset --hard + git clean -fd), поэтому игнорируемые пути, такие как node_modules, venv и результаты сборки, никогда не затрагиваются.

В настольном приложении это Настройки → Дополнительно → Локальные изменения при обновлении в приложении.

Только предварительный просмотр: vibeos update --check

Хотите узнать, доступно ли обновление, перед его загрузкой? Выполните vibeos update --check — он получает и сравнивает коммиты с origin/main. Никакие файлы не изменяются, шлюз не перезапускается. Полезно в скриптах и задачах cron, которые срабатывают по условию «есть обновление».

Устранение неполадок: Authentication failed при vibeos update --check

Если проверка или обновление падает с ошибкой аутентификации GitHub, обычно виноват заглушечный GITHUB_TOKEN / GH_TOKEN в ~/.vibeos/.env (или устаревшем ~/.vibeos/.env) — значения вроде ***, x или changeme перекрывают рабочий логин gh и ломают неинтерактивный git fetch.

1. Откройте ~/.vibeos/.env и закомментируйте или удалите заглушки:

   # GITHUB_TOKEN=***   # заглушка — не задавать

2. Используйте настоящий токен или gh auth login (VibeOS повторяет fetch через gh auth token, когда env-заглушки сняты).
3. Проверьте: vibeos doctor (предупреждает о placeholder-токенах) и vibeos update --check.

Полное резервное копирование перед обновлением: --backup

Для ценных профилей (продакшн-шлюзы, общие командные установки) вы можете включить полное резервное копирование VIBEOS_HOME перед pull (конфигурация, аутентификация, сессии, навыки, спаривание):

vibeos update --backup

Или сделайте это поведением по умолчанию для каждого запуска:

# ~/.vibeos/config.yaml
updates:
  pre_update_backup: true

--backup был всегда включённым поведением в ранних сборках, но он добавлял минуты к каждому обновлению на больших домашних каталогах, поэтому теперь он опционален. Облегчённый снимок данных спаривания, описанный выше, по-прежнему выполняется безусловно.

Windows: запущен другой vibeos.exe

На Windows vibeos update откажется выполняться, если обнаружит другой процесс vibeos.exe, удерживающий исполняемый файл точки входа venv — чаще всего это фоновый процесс настольного приложения VibeOS Desktop, открытый REPL vibeos в другом терминале или работающий шлюз:

$ vibeos update
✗ Запущен другой vibeos.exe:
    PID 12345  vibeos.exe

  Обновление сейчас не удастся перезаписать ...\venv\Scripts\vibeos.exe, потому что
  Windows блокирует REPLACE для запущенного исполняемого файла.

  Закройте VibeOS Desktop, выйдите из всех открытых REPL `vibeos` и
  остановите шлюз (`vibeos gateway stop`) перед повторной попыткой.
  Переопределите с помощью `vibeos update --force`, если вы уже
  подтвердили, что эти процессы не будут записывать в venv.

Закройте перечисленные процессы и повторите попытку. Если вы уверены, что параллельный процесс не помешает (редко — обычно полезно только когда ошибочно атрибутируется антивирусный shim), передайте --force, чтобы пропустить проверку. В этом случае установщик всё равно повторит попытку переименования .exe с экспоненциальной задержкой и, при устойчивых блокировках, запланирует замену на следующую перезагрузку через MoveFileEx(MOVEFILE_DELAY_UNTIL_REBOOT), чтобы обновление могло завершиться.

Ожидаемый вывод выглядит так:

$ vibeos update
Обновление VibeOS...
📥 Загрузка последнего кода...
Уже актуально.  (или: Обновление abc1234..def5678)
📦 Обновление зависимостей...
✅ Зависимости обновлены
🔍 Проверка новых параметров конфигурации...
✅ Конфигурация актуальна  (или: Найдено 2 новых параметра — запуск миграции...)
🔄 Перезапуск шлюзов...
✅ Шлюз перезапущен
✅ VibeOS успешно обновлён!

Рекомендуемая проверка после обновления

vibeos update выполняет основной путь обновления, но быстрая проверка подтверждает, что всё прошло чисто:

1. git status --short — если дерево неожиданно грязное, проверьте перед продолжением
2. vibeos doctor — проверяет конфигурацию, зависимости и работоспособность служб
3. vibeos --version — подтвердите, что версия увеличилась как ожидалось
4. Если вы используете шлюз: vibeos gateway status
5. Если doctor сообщает о проблемах npm audit: выполните npm audit fix в указанном каталоге

Грязное рабочее дерево после обновления

Если git status --short показывает неожиданные изменения после vibeos update, остановитесь и проверьте их перед продолжением. Обычно это означает, что локальные изменения были повторно применены поверх обновлённого кода, или шаг зависимостей обновил файлы блокировок.

Если ваш терминал отключился во время обновления

vibeos update защищает себя от случайной потери терминала:

• Обновление игнорирует SIGHUP, поэтому закрытие SSH-сессии или окна терминала больше не прерывает его на полпути. Дочерние процессы pip и git наследуют эту защиту, поэтому окружение Python не может остаться наполовину установленным из-за разорванного соединения.
• Весь вывод дублируется в ~/.vibeos/logs/update.log во время выполнения обновления. Если ваш терминал исчез, переподключитесь и проверьте лог, чтобы узнать, завершилось ли обновление и успешен ли перезапуск шлюза:

tail -f ~/.vibeos/logs/update.log

• Ctrl-C (SIGINT) и завершение работы системы (SIGTERM) по-прежнему обрабатываются — это намеренные отмены, а не случайности.

Вам больше не нужно оборачивать vibeos update в screen или tmux, чтобы пережить потерю терминала.

Проверка текущей версии

vibeos version

Сравните с последним релизом на vibeos.com.ru/download.

Обновление из мессенджеров

Вы также можете обновиться напрямую из Telegram, Discord, Slack, WhatsApp или Teams, отправив:

/update

Это загружает последний код, обновляет зависимости и перезапускает работающие шлюзы. Бот ненадолго отключится во время перезапуска (обычно 5–15 секунд), а затем возобновит работу.

Ручное обновление

Если вы установили вручную (не через быстрый установщик):

cd /path/to/vibeos-agent
export VIRTUAL_ENV="$(pwd)/venv"

# Загрузка последнего кода
git pull origin main

# Переустановка (устанавливает новые зависимости)
uv pip install -e ".[all]"

# Проверка новых параметров конфигурации
vibeos config check
vibeos config migrate   # Интерактивное добавление отсутствующих параметров

Инструкции по откату

Если обновление вызвало проблему, вы можете откатиться до предыдущей версии:

cd /path/to/vibeos-agent

# Список последних версий
git log --oneline -10

# Откат до конкретного коммита
git checkout <хеш-коммита>
uv pip install -e ".[all]"

# Перезапуск шлюза, если он запущен
vibeos gateway restart

Чтобы откатиться до конкретного тега релиза (укажите ваш предыдущий тег — например, недавний релиз вроде v2026.5.16 или любой более ранний тег из git tag --sort=-version:refname):

git checkout vX.Y.Z
uv pip install -e ".[all]"

предупреждение

Откат может вызвать несовместимость конфигурации, если были добавлены новые параметры. Выполните vibeos config check после отката и удалите нераспознанные параметры из config.yaml, если возникнут ошибки.

Примечание для пользователей Nix

Nix больше не является явно поддерживаемым путём установки (только «best-effort») — см. Установка через Nix. Если вы установили через Nix flake, обновления управляются через менеджер пакетов Nix:

# Обновление входа flake
nix flake update vibeos-agent

# Или пересборка с последней версией
nix profile upgrade vibeos-agent

Установки Nix неизменяемы — откат обрабатывается системой поколений Nix:

nix profile rollback

См. Установка через Nix для получения дополнительной информации.

---

Удаление

vibeos uninstall

Программа удаления предлагает вам сохранить файлы конфигурации (~/.vibeos/) для будущей переустановки.

Ручное удаление

rm -f ~/.local/bin/vibeos
rm -rf /path/to/vibeos-agent
rm -rf ~/.vibeos            # Опционально — оставьте, если планируете переустановку

к сведению

Если вы установили шлюз как системную службу, сначала остановите и отключите его:

vibeos gateway stop
# Linux: systemctl --user disable vibeos-gateway
# macOS: launchctl remove ai.vibeos.gateway