Managing Multiple Projects with Codex: CLI vs App Workflows

Mar 13, 2026

The Problem

I had six terminal tabs open. Three were running Codex sessions in different projects. Two were for git operations. One was a scratchpad I’d forgotten about.

I typed a command intended for my frontend project. It ran in my backend API directory instead. The AI started modifying the wrong codebase.

This wasn’t the first time. I was losing hours to context-switching overhead. Terminal tab after terminal tab, each with a different project context, each with its own conversation history I couldn’t search.

I needed a better system for managing multiple Codex sessions.

What I Tried First

The Naive Terminal Approach

My initial setup was simple: one terminal tab per project.

# Terminal tab 1
cd ~/projects/frontend-app && codex

# Terminal tab 2
cd ~/projects/backend-api && codex

# Terminal tab 3
cd ~/projects/shared-libs && codex

This works fine with two projects. But at five projects, I hit problems:

Tab blindness: All terminals look the same. I’d forget which tab was which project.
Lost conversations: If I closed a tab by accident, that conversation was gone.
No search: Can’t grep through Codex conversation history.
Session persistence: Terminal crashes meant lost work.

A Reddit user described the same issue:

“Using CLI with multiple terminals have two issues: 1) Easy tracking and switching between running terminals 2) Viewing and searching across session transcripts”

This matched my experience exactly.

First Attempt: tmux Sessions

I moved to tmux for better organization.

# Create named sessions for each project
tmux new -s frontend -c ~/projects/frontend-app
tmux new -s backend -c ~/projects/backend-api
tmux new -s docs -c ~/projects/docs

# Start codex in each session
# (inside each tmux session)
codex

# List all sessions
tmux ls

# Switch between sessions
tmux switch -t backend
# Or use Ctrl-b s for interactive selection

This helped with naming. Now I had “frontend”, “backend”, and “docs” sessions instead of anonymous tabs.

But problems remained:

Still couldn’t search across conversation history
Still no visual overview of all projects
Worktrees were still manual to manage

Second Attempt: iTerm2 with Virtual Desktops

A Reddit user shared their CLI workflow:

“I prefer CLI. iTerm2 tabs in multiple windows in multiple virtual desktops. My setup: one iTerm2 window per project in own virtual desktop.”

I tried this approach:

Desktop 1: Frontend project
  - iTerm2 window with codex session
  - VS Code for editing

Desktop 2: Backend API
  - iTerm2 window with codex session
  - IntelliJ IDEA for editing

Desktop 3: Shared libraries
  - iTerm2 window with codex session
  - Editor of choice

This worked better for visual separation. Swipe between desktops, and the context is clear.

But managing virtual desktops gets tedious. And I still couldn’t search across conversations.

The Turning Point: Trying the Codex App

I’d dismissed the standalone Codex App as unnecessary. “Why add another application?”

Then I read this comment:

“Having the threads in a UI, be named and also being able to link multiple projects // switching between them is a great workflow.”

I gave it a serious try. Within an hour, I saw what I’d been missing.

Named Threads

In the App, each conversation gets a name. Not just “terminal tab 3” but “frontend-auth-feature” or “api-rate-limiting”.

Project: frontend-app
  - Auth bug fix (March 10)
  - Add dark mode (March 11)
  - Performance optimization (March 12)

Project: backend-api
  - Database migration (March 10)
  - Add rate limiting (March 12)

I could find previous conversations. I could see what I’d worked on. No more grepping through shell history.

Visual Project Switching

Click a project. Start talking. No cd commands. No wondering which directory I’m in.

Cross-Repository Queries

Another Reddit user mentioned:

“Its really good to ask questions cross repository.”

This became the killer feature. I could ask about code across multiple projects without juggling terminal sessions.

Worktree Management

One comment stood out:

“It’s easier to work with worktree as well, much better than controlling this by hand.”

I’d been managing git worktrees manually for parallel feature branches. The App handled this better.

What Still Works Better in CLI

The App isn’t perfect for everything. I kept the CLI for certain workflows.

Remote Development

Working over SSH? CLI + VS Code Remote is smoother. The App needs more configuration.

Scripting and Automation

# CLI works in scripts
for project in frontend backend docs; do
  cd ~/projects/$project
  codex "Check for outdated dependencies"
done

The CLI integrates with automation. The App doesn’t.

Maximum Control

The CLI exposes every option. For power users who want fine-grained control, the terminal is still king.

Third-Party Tools: Agent Sessions

A Reddit user pointed to a tool that addresses CLI’s main weakness:

“See jazzyalex.github.io/agent-sessions for CLI transcript search, better than App’s search functionality.”

Agent Sessions provides:

Easy tracking of running terminals
Search across session transcripts
Better search than the App’s built-in functionality

For CLI diehards, this fills the gap.

What I Use Now: Hybrid Approach

I stopped trying to pick one approach. Instead, I use each for what it does best.

Codex App for:

Project organization
Cross-repository questions
Long-running conversations I need to reference later
Visual overview of active work

CLI for:

Quick commands
Remote development
Scripted automation
CI/CD integration

CLI + VS Code for:

Active coding where I need to see diffs
Single-project deep work
Times when I want editor integration

Common Mistakes I Made

Mistake 1: Opening Too Many Terminals

Six tabs became ten. Ten became chaos. Each new project added another anonymous terminal.

Solution: Use named sessions (tmux) or named projects (App).

Mistake 2: Not Naming Conversations

When I finally found the App’s naming feature, I realized how much time I’d wasted searching for previous context.

Now every conversation gets a descriptive name immediately.

Mistake 3: Ignoring Session Persistence

Terminal crashes lost work. I didn’t think about persistence until I lost an important conversation.

Solution: Use the App (automatic persistence) or tmux (manual session management).

Mistake 4: Not Using Worktrees

Working on the same repo from multiple terminals caused conflicts. Git worktrees solve this, and the App handles them automatically.

Feature Comparison

Feature	CLI + tmux	Codex App
Named sessions	Manual setup	Built-in
Project switching	`tmux switch` or `cd`	Click sidebar
Conversation search	None (use Agent Sessions)	Built-in
Cross-repo queries	Manual	Built-in
Worktree handling	Manual	Automatic
Remote development	Full support	Limited
Automation/scripts	Full support	None
Visual organization	None	Full GUI

For developers with 2 or fewer active projects: CLI is fine. The overhead of the App doesn’t pay off.

For developers juggling 3+ projects: Try the Codex App. The project organization and named conversations reduce mental overhead significantly.

For CLI power users: Stick with CLI. Add tmux for session management. Consider Agent Sessions for transcript search.

For teams: The App lowers the barrier for less technical team members who prefer clicking over typing.

The One-Week Test

If you’re unsure, run a test:

Days 1-3: CLI only with your current setup Days 4-7: Codex App only

Track:

Time spent context-switching
Times you lost conversation history
Times you couldn’t find previous work
Overall frustration level

For me, the App won on organization. The CLI won on control. I use both.

Summary

Managing multiple Codex sessions doesn’t have to mean drowning in terminal tabs. The Codex App excels at multi-project organization with named threads and visual project switching. The CLI excels at automation and remote work.

The Reddit comment that captured it best:

“Code quality is equal… Having the threads in a UI, be named and also being able to link multiple projects // switching between them is a great workflow.”

Code quality is the same either way. The difference is in managing your workflow across multiple contexts.

Stop trying to pick one. Use the App for organization. Use the CLI for power. Use both for what they do best.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!