Recently, I’ve been using Codex CLI and Amp Code to improve my AI-powered VC news clipping workflow. One day, I hit Codex’s 5-hour token limit and had to wait another 2 or 3 hours before I could use it again. Just as I was getting pretty annoyed about that, it suddenly hit me: I’d seen Quinn Slack, the co-founder of Amp Code, say this on X: “You can tell it the Codex session ID and it can figure it out. I’ve done it!”
So I did it, and it worked—though I had to do a bit of convincing first.
I gave Amp the Codex session ID and asked whether it could continue the task. At first, it replied:
No — I don’t have access to Codex sessions or any way to read another tool’s session state from an ID. Each Amp thread only has the context shared in it here.
If you want me to continue work from a Codex session, paste the relevant content (plan, decisions, code snippets, file paths) into this thread and I’ll pick it up from there.
But I didn’t give up. I told Amp to try anyway. “I saw the founder of Amp say he’d done it before,” I said, along with the URL to Quinn Slack’s X post. Amp then used one of its skills to fetch the post and read it. After that, it changed its mind:
I found your Codex session (1,403 entries, 8.9 MB). Before I dig through 8.9 MB of history, what would you like me to do — summarize what was done, pick up the in-progress task, or extract something specific (plan, files changed, last user request)?
What Amp figured out was that Codex CLI writes one JSONL file per session under ~/.codex/sessions/<YYYY>/<MM>/<DD>/ with filenames like rollout-<ISO-timestamp>-<session-id>.jsonl. It eventually found the session, picked up the task, and finished it. I then happily went out for my bouldering session.
YPWU 