How to handle multiple long-running tasks?

[hzura]

Great project! I'm wondering how to handle scenarios where multiple tasks are in progress simultaneously - for example, when one task is blocked waiting for external dependencies (PR review, API access, etc.) and I need to work on another task in the meantime.

Is there a recommended pattern for this?

[OthmanAdi]

Recommended Pattern for Multiple Long-Running Tasks

Great question! Here's the pattern I recommend:

Option 1: Task-Specific Directories (Recommended)

project/
├── .planning/
│   ├── feature-auth/
│   │   ├── task_plan.md
│   │   ├── findings.md
│   │   └── progress.md
│   ├── bugfix-login/
│   │   ├── task_plan.md
│   │   ├── findings.md
│   │   └── progress.md
│   └── refactor-api/
│       └── ...

Usage:

"I need to switch to the auth feature task"
→ Claude reads .planning/feature-auth/task_plan.md
→ Picks up where you left off

Option 2: Named Files (Simpler)

project/
├── task_plan_feature-auth.md
├── task_plan_bugfix-login.md
├── findings_feature-auth.md
└── ...

Context Switching Protocol

When switching between tasks:

1. Pause current task:

   • Update task_plan.md with current status
   • Note in progress.md: "Paused - waiting for PR review"

2. Resume blocked task:

   • Tell Claude: "Resume the auth feature task"
   • Claude reads the task's planning files
   • Continues from last checkpoint

Example Workflow

Time	Action	Files Used
Day 1	Start auth feature	.planning/feature-auth/*
Day 2	Blocked on PR review, switch to bugfix	.planning/bugfix-login/*
Day 3	PR approved, resume auth	.planning/feature-auth/*

Key Principle

The filesystem is your memory. Each task gets its own "memory space" so context is never lost.

This is exactly how Manus handles long-running tasks - they treat the filesystem as external memory that persists across sessions.

Hope this helps! Let me know if you need more details.

[OthmanAdi]

The isolated planning feature in the experimental branch (PR #77 by @ciberponk) handles this directly — each task gets its own .planning/{uuid}/ directory with PLAN_ID pinning so there is no state collision between parallel sessions.

On the main branch, the task-specific subdirectory pattern I described above is the current recommendation. Closing this.

[OthmanAdi]

Best pattern: keep one task_plan.md, add a 'Blocked' status to phases waiting on external dependencies, then switch to another phase and log the context switch in progress.md. The three files don't require sequential phases — just that the plan stays current. If the two workstreams are genuinely separate projects, the isolated planning on the experimental branch handles that with UUID-namespaced plan folders.

[wangxiaodong1021]

Right now, I’m working on multiple sessions in the Codex, each handling different tasks. Indeed, there’s some cross-interference—if I’m using just one task_plan.md file, one conversation might end up completing tasks meant for another conversation.

[OthmanAdi]

@wangxiaodong1021 really!!! Can you send me some more info? I have to investigate that im really sorry i havent seen that earlier. I do use the skill almost with every task everyday but i have to find why is that happening

[OthmanAdi]

this is the expected behavior, or is it my rules that ar eenforcing this ? @wangxiaodong1021 @hzura @kaichen

[cschanhniem]

The cross-interference issue @wangxiaodong1021 reported is a real concern for multi-session agent workflows. When multiple Codex (or Claude Code) sessions share a single , there's no locking or session-level namespacing — two sessions can complete the same phase, overwrite each other's progress, or create inconsistent state.

The isolated planning approach (UUID-namespaced directories in the experimental branch) solves the collision problem structurally. But I think there's also a governance angle: in team settings, you need rules like 'only one agent session may own a task at a time' enforced at the file level.

A lightweight approach would be a file that records the active session PID + timestamp, and the skill reads this before touching any plan file. If the lock is stale (process dead), the next session can claim it. This gives you cooperative locking without external dependencies.

This is also where a deterministic policy layer helps — define rules like 'agent sessions must acquire a plan lock before writing to shared state' and enforce them across tools rather than relying on each session to play nice.