Building a Codex Session Manager with Codex and Jira

A practical experiment in structured AI-assisted development

I built a Codex Session Manager to solve a problem I kept running into: once a Codex-based task grows beyond a single sitting, everything starts to fray.

You lose context.
You forget why decisions were made.
And resuming work feels more like starting over than continuing.

The app I ended up with lets you create Codex sessions tied to folders, resume them days later, and work on long-running tasks without constantly re-explaining context.

But the real experiment wasn't the app itself.

It was what happened when Codex was paired with deliberate structure.

Download the Mac version of you GUI for Codex here:

If you want a Windows version, download the source from the github-link in the bottom; it should build and run in Windows just fine.

Why I deliberately introduced Jira

The idea to use Jira didn't come from Codex came from my frustrations with the loss of focus that Codex would inevitably find it self in after a log day of coding.

I believe this could just as well have been done with Trello, a markdown file, or even a simple list. Any of those would have been better than nothing. I chose Jira because it's the industry standard, and I wanted to see how a professional-grade planning tool would shape the collaboration between a human and an AI.

It worked very well indeed.

Jira as the backbone of the workflow

Jira wasn't used as a passive record of work. It became the execution track.

Each ticket defined:

• One responsibility

• Clear acceptance criteria

• A concrete, testable definition of done

Codex was never asked to "improve something" or "clean things up". It was asked to satisfy a specification.

That framing turned out to be crucial, especially when sessions were resumed days later. The intent was still there, and Codex stayed aligned instead of drifting.

Writing better tickets with Codex

One unexpected benefit was using Codex to help write the tickets themselves.

If a ticket was vague, implementation tended to be messy. That became immediate feedback that the work simply wasn't ready yet.

I employed a simple rule from my daily work:

If a ticket can't be tested, it isn't ready.

Codex helped turn fuzzy ideas into concrete, testable acceptance criteria before any code was written. That alone removed a surprising amount of friction.

Codex as a disciplined implementer

Once tickets were clear, Codex became extremely reliable.

The loop was simple:

1. Resume the session

2. Hand Codex a ticket

3. Let it implement exactly what was specified

4. Verify behavior and move on

There was very little scope creep and almost no need to wrestle with the assistant. When something didn't work, the fix was almost always to improve the specification rather than arguing about the output.

When structure wasn't enough

One important nuance is that Jira isn't always the right tool.

Terminal resizing exposed a deeper issue in the underlying TTY implementation. At that point, the problem wasn't well understood yet, and no amount of ticket precision would have helped.

This is where I temporarily stepped away from Jira and switched to exploration mode.

I dove into the terminal stack, asked Codex questions, tried variations, and reasoned through the behavior together. It was unstructured and conversational. In other words, I vibe-coded.

That exploration led to a larger architectural decision: replacing the terminal implementation entirely.

Only after that decision did structure become useful again.

Structure and exploration work together

This project made one pattern very clear:

• Explore when the problem isn't understood

• Add structure once it is

The tooling made it easy to pause work, explore freely, and then return later with clarity and discipline intact.

Jira didn't replace exploration. It contained it.

A note on experimental features

There is also an experimental feature where Codex can request commands to be run in separate tabs. It's intentionally optional and still evolving.

It's useful in some cases, but it's not the core value here.

What this tool actually enables

Codex already supports long-lived sessions.
The problem is discoverability and ergonomics.

If you know the session GUID, or you're willing to dig through history, you can resume work. In practice, that friction is enough to push people back into starting fresh.

What this tool adds is not new capability, but usable structure:

• A clear, visual overview of the sessions you're actively working on

• The ability to resume work without hunting for identifiers

• A GUI for toggling session-specific settings

• A place to wire in integrations and workflow behavior deliberately

That difference matters.

It's the difference between a feature existing and a feature being used.

Why this made pairing Codex with Jira effective

Once sessions were easy to find and resume, Jira stopped being a separate system you had to mentally reconstruct.

Tickets could be revisited days later.
Context didn't need to be re-established.
Decisions survived interruptions.

That's what made pairing Codex with Jira not just possible, but effective.

The tool didn't replace Codex's capabilities.
It made them practical at human scale.

The takeaway

This project produced a working app, but more importantly, it produced a workflow that actually holds up over time.

If you want AI tools to behave like engineers, you have to give them the same environment engineers thrive in: continuity, constraints, and clear intent.

The tools don't replace judgment.
They reward it.

Find the project on github here: https://github.com/JohnDoktor/Codex-Session-Manager