OpenAI Codex на двух устройствах: как синхронизировать сессии без боли

Я работаю с OpenAI Codex в двух режимах. Дома — за мощным ПК с двумя экранами и в поездках на дачу/отдых/по работе — с ноутбука.

И довольно быстро столкнулся с неожиданной проблемой:
контекст, сессии и история Codex не синхронизируются между устройствами. OpenAI этого просто не предусмотрели!

В чём проблема

Если вы активно используете Codex, у вас постепенно накапливаются:

И всё это:

В итоге:

Начал задачу на ПК → продолжить на ноутбуке уже нельзя

Почему так устроено

Судя по наблюдениям, Codex хранит состояние локально:

Это даёт:

Но ломает мульти-девайс сценарий.

Простая идея решения

Вместо того чтобы бороться с Codex — можно принять его модель и работать поверх неё.

Идея максимально простая:

Синхронизировать папку состояния Codex между устройствами


Что я сделал

Я сделал небольшой CLI-инструмент — codexSync:

GitHub: https://github.com/kroxiksut/codexSync

PyPI: https://pypi.org/project/codexsync/

Как это работает

Схема максимально простая:

  1. Вы указываете:

    • где лежит состояние Codex

    • куда его синхронизировать

  2. Перед работой:

    • подтягиваете актуальное состояние

  3. После работы:

    • отправляете изменения

Минимальная инструкция для старта

python -m codexsync init-config
или
python -m codexsync init-config --output D:\codexSync\config.toml

Отредактируйте файл конфига, укажите пути до директории .codex и директорию, в которая будет рабочей для утилиты. Можно настроить и другие параметры под себя в конфиг файле или оставить их по умолчанию.

Проверить правильность конфига можно командой

python -m codexsync -c config.toml validate

Далее можно посмотреть план, что утилита собирается сделать, сделать тестовый прогон без реальной записи и синхронизировать изменения


python -m codexsync -c config.toml plan
python -m codexsync -c config.toml sync --dry-run
python -m codexsync -c config.toml sync --apply

Почему не просто облако

Можно сказать:

"Закинь папку в Dropbox и всё"

Но на практике:

codexSync добавляет:

Ограничения

Важно понимать:

Помощь с тестированием

Хочу проверить, как инструмент ведёт себя в разных конфигурациях:

Если у вас есть возможность протестировать — буду очень благодарен за любой фидбек.

Остались вопросы, предложения, замечания, есть идеи по доработке? Пишите комментарии или в личку.

@krox
22.03.2026 13:37 UTC
Первоисточник

Комментарии

@R_Sanych
22.03.2026 09:38 UTC
0

А как решить проблему что Code Claude очень долго думает, сессия длинная была. Раньше за секунду ответ давал, теперь приходится ждать по 3-5 минут, что очень неудобно. Vpn включен, тариф оплачен. Посоветуйте!

@krox
22.03.2026 09:42 UTC
0

Похоже, это скорее про сам Codex, не про синхронизацию.

Уточните, пожалуйста, какие модели используете?
Если с сильным рассуждением (reasoning), то они действительно могут отвечать заметно дольше, особенно на длинных сессиях.

Из наблюдений:

  • чем длиннее диалог, тем сильнее может расти время ответа

  • иногда помогает начать новую сессию и перенести краткий контекст

У вас примерно какой объём сессии сейчас?

Я сам с таким сильным замедлением пока не сталкивался, поэтому интересно понять, в каких условиях это проявляется. Если вдруг найдёте обсуждения или решение (например, на Reddit или профильных чатах) — будет полезно, если поделитесь здесь.

22.03.2026 09:46 UTC
0

Model Sonet 4.6. Объем сессии не знаю как посмотреть, но по времени недели две по несколько часов в день)

22.03.2026 09:49 UTC
0

Похоже, вы сейчас не про Codex.

Sonnet 4.6 — это модель от Anthropic (Claude), а не из экосистемы OpenAI Codex. У них модели ChatGPT разных версий и ChatGPT-codex

Но поведение, которое вы описываете, в целом похоже: при очень длинных сессиях (особенно если там много контекста/кода) ответы могут заметно замедляться.

В таком случае обычно помогает:

  • начать новую сессию

  • перенести краткий контекст вручную

«Две недели по несколько часов в день» — это как раз тот случай, где контекст уже может быть очень большим.

Если разберётесь, от чего именно зависит задержка — будет интересно узнать

22.03.2026 09:58 UTC
0

Так тогда и сделаю, начну новую сессию с краткой историей старой сессии, надеюсь мысль модель не потеряет) Спасибо!

22.03.2026 10:05 UTC
+1

В старой сессии попроси выжимку в md файл сделать.

22.03.2026 18:57 UTC
+1

Если самый простой вариант:

Создаёте файл типа my-work-journal.md к примеру после каждого действия (исполнения промпта) пусть пишет туда короткую выжимку чего поменял с timestamp к примеру, и второй файл например my-work-backlog.md перед тем как начать новую сессию пусть пишет туда на чем остановились и что планируете делать дальше (кратко или подробно, тут уже по ситуации). Ну и собственно должен быть хотя бы основной файл с ТЗ или что у вас там есть (то над чем работаете). В новой сессии пихаете ему файл ТЗ, просите прочитать конец журнала изменений (можно в журнал писать только последние изменения, если вам не нужна вся история попыток, удач/не удач и так далее) и backlog что бы не рассказывать чего вы там собирались делать. Это примитивный вариант, но работает, когда у вас объёмная работа, которая не помещается в одно контекстное окно. Лучше конечно изначально большую задачу пилить на селкие составляющие

22.03.2026 18:59 UTC
0

А, ну и что бы весь этот входной контекст меньше ел токенов, просите писать его на английском

@R_Sanych
22.03.2026 09:47 UTC
0

Коды по тысячи строк доходят)

@past
22.03.2026 19:07 UTC
+1

Тут вижу проблему XY.

Старайтесь не работать длинными сессиями. Делить эрпики на задачки, задачки на подзадачки. Пока они не будут у Вас укладываться в 1 копоткоживущую сессию. Всё ± как в классической разработке. Кроме того длинная сессия - замусоренных контент. Лучше по окончании задачки заставляйте кодекс обновлять марудауны с контекстом. Если всё же никак не можете обходиться без длинных сессий, просто кладите их в гит вместе с проектом.

@krox
23.03.2026 01:50 UTC
+1

Да, согласен, это в целом хороший подход — разбивать задачи и не раздувать сессии.

Я как раз пришёл к похожему выводу: длинные диалоги быстро начинают «засоряться» и хуже работают.

В моём случае проблема была чуть в другом — хотелось сохранять и переносить уже накопленный контекст между устройствами, а не терять его при переключении.

Поэтому и появился инструмент для синхронизации.

Но как альтернатива — да, короткие сессии + явное сохранение контекста (в markdown или git) выглядит хорошей стратегией. При этом это скорее дополняет подход, чем заменяет — в моём случае как раз хотелось сохранить и переносить накопленный контекст между устройствами без ручных действий.