Я работаю с OpenAI Codex в двух режимах. Дома — за мощным ПК с двумя экранами и в поездках на дачу/отдых/по работе — с ноутбука.
И довольно быстро столкнулся с неожиданной проблемой:
контекст, сессии и история Codex не синхронизируются между устройствами. OpenAI этого просто не предусмотрели!
В чём проблема
Если вы активно используете Codex, у вас постепенно накапливаются:
сессии (диалоги с агентом)
промежуточные состояния
контекст проекта
заметки и саммари
И всё это:
нельзя просто "подтянуть" с другого устройства
нельзя удобно объединить
нельзя нормально почистить (только архив)
В итоге:
Начал задачу на ПК → продолжить на ноутбуке уже нельзя
Почему так устроено
Судя по наблюдениям, Codex хранит состояние локально:
файлы сессий
служебные данные
возможно SQLite
Это даёт:
скорость
приватность
Но ломает мульти-девайс сценарий.
Простая идея решения
Вместо того чтобы бороться с Codex — можно принять его модель и работать поверх неё.
Идея максимально простая:
Синхронизировать папку состояния Codex между устройствами
Что я сделал
Я сделал небольшой CLI-инструмент — codexSync:
находит нужные папки Codex
синхронизирует их между устройствами
работает через любую папку (облако, NAS)
не лезет внутрь Codex
GitHub: https://github.com/kroxiksut/codexSync
PyPI: https://pypi.org/project/codexsync/
Как это работает
Схема максимально простая:
-
Вы указываете:
где лежит состояние Codex
куда его синхронизировать
-
Перед работой:
подтягиваете актуальное состояние
-
После работы:
отправляете изменения
Минимальная инструкция для старта
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 добавляет:
предсказуемость
dry-run (plan)
контроль
Ограничения
Важно понимать:
это не официальное решение
нет realtime синка
нужно закрывать Codex перед синхронизацией, в том числе закрывая фоновый процесс. Если Codex не закрыт, сценарий синхронизации выполняться не будет. Если остался фоновый процесс - утилита предложит сама его завершить.
Помощь с тестированием
Хочу проверить, как инструмент ведёт себя в разных конфигурациях:
macOS ↔ macOS
macOS ↔ Windows
Если у вас есть возможность протестировать — буду очень благодарен за любой фидбек.
Остались вопросы, предложения, замечания, есть идеи по доработке? Пишите комментарии или в личку.
Комментарии (11)
past
22.03.2026 09:38Тут вижу проблему XY.
Старайтесь не работать длинными сессиями. Делить эрпики на задачки, задачки на подзадачки. Пока они не будут у Вас укладываться в 1 копоткоживущую сессию. Всё ± как в классической разработке. Кроме того длинная сессия - замусоренных контент. Лучше по окончании задачки заставляйте кодекс обновлять марудауны с контекстом. Если всё же никак не можете обходиться без длинных сессий, просто кладите их в гит вместе с проектом.
krox Автор
22.03.2026 09:38Да, согласен, это в целом хороший подход — разбивать задачи и не раздувать сессии.
Я как раз пришёл к похожему выводу: длинные диалоги быстро начинают «засоряться» и хуже работают.
В моём случае проблема была чуть в другом — хотелось сохранять и переносить уже накопленный контекст между устройствами, а не терять его при переключении.
Поэтому и появился инструмент для синхронизации.
Но как альтернатива — да, короткие сессии + явное сохранение контекста (в markdown или git) выглядит хорошей стратегией. При этом это скорее дополняет подход, чем заменяет — в моём случае как раз хотелось сохранить и переносить накопленный контекст между устройствами без ручных действий.
R_Sanych
А как решить проблему что Code Claude очень долго думает, сессия длинная была. Раньше за секунду ответ давал, теперь приходится ждать по 3-5 минут, что очень неудобно. Vpn включен, тариф оплачен. Посоветуйте!
krox Автор
Похоже, это скорее про сам Codex, не про синхронизацию.
Уточните, пожалуйста, какие модели используете?
Если с сильным рассуждением (reasoning), то они действительно могут отвечать заметно дольше, особенно на длинных сессиях.
Из наблюдений:
чем длиннее диалог, тем сильнее может расти время ответа
иногда помогает начать новую сессию и перенести краткий контекст
У вас примерно какой объём сессии сейчас?
Я сам с таким сильным замедлением пока не сталкивался, поэтому интересно понять, в каких условиях это проявляется. Если вдруг найдёте обсуждения или решение (например, на Reddit или профильных чатах) — будет полезно, если поделитесь здесь.
R_Sanych
Model Sonet 4.6. Объем сессии не знаю как посмотреть, но по времени недели две по несколько часов в день)
krox Автор
Похоже, вы сейчас не про Codex.
Sonnet 4.6 — это модель от Anthropic (Claude), а не из экосистемы OpenAI Codex. У них модели ChatGPT разных версий и ChatGPT-codex
Но поведение, которое вы описываете, в целом похоже: при очень длинных сессиях (особенно если там много контекста/кода) ответы могут заметно замедляться.
В таком случае обычно помогает:
начать новую сессию
перенести краткий контекст вручную
«Две недели по несколько часов в день» — это как раз тот случай, где контекст уже может быть очень большим.
Если разберётесь, от чего именно зависит задержка — будет интересно узнать
R_Sanych
Так тогда и сделаю, начну новую сессию с краткой историей старой сессии, надеюсь мысль модель не потеряет) Спасибо!
krox Автор
В старой сессии попроси выжимку в md файл сделать.
SlavaVSLK
Если самый простой вариант:
Создаёте файл типа my-work-journal.md к примеру после каждого действия (исполнения промпта) пусть пишет туда короткую выжимку чего поменял с timestamp к примеру, и второй файл например my-work-backlog.md перед тем как начать новую сессию пусть пишет туда на чем остановились и что планируете делать дальше (кратко или подробно, тут уже по ситуации). Ну и собственно должен быть хотя бы основной файл с ТЗ или что у вас там есть (то над чем работаете). В новой сессии пихаете ему файл ТЗ, просите прочитать конец журнала изменений (можно в журнал писать только последние изменения, если вам не нужна вся история попыток, удач/не удач и так далее) и backlog что бы не рассказывать чего вы там собирались делать. Это примитивный вариант, но работает, когда у вас объёмная работа, которая не помещается в одно контекстное окно. Лучше конечно изначально большую задачу пилить на селкие составляющие
SlavaVSLK
А, ну и что бы весь этот входной контекст меньше ел токенов, просите писать его на английском