[macOS][Codex Desktop] OpenClaw subagent/internal sessions appear as top-level sidebar chats and some cannot be archived

[hanho1188]

Summary

On Codex Desktop for macOS, internal OpenClaw child sessions / subagent threads are appearing as normal top-level conversations in the Codex project sidebar.

This started happening recently. Previously, OpenClaw could perform delegated/subagent work without filling the Codex sidebar with separate user-visible conversations.

Now, a single normal task can result in many additional sidebar entries.

Examples of the titles that appear:

• [Subagent Context] You are running as a subagent...
• [Inter-session message] sourceSession=agent:...
• Conversation info: [openclaw]...
• OpenClaw assembled context...
• read-only test / recovery / validation sessions
• internal safety-check and pipeline recovery sessions

These are not conversations that I manually created.

Environment

• OS: macOS
• Codex Desktop bundled runtime: 0.153.4
• OpenClaw: 2026.9.1
• OpenClaw is connected to Codex and uses sessions/subagents for some tasks.

I also have an older Codex CLI installed at /opt/homebrew/bin/codex (0.147.0), but the issue is occurring in the Codex Desktop app.

What happens

My project originally had only two conversations that I intentionally created:

1. (코덱스)카드뉴스자동화(ver.1)
2. (코덱스)카드뉴스자동화(ver.2) 개발중

After OpenClaw performed normal validation, recovery, file lookup, and subagent work, many additional conversations started appearing in the Codex sidebar.

They include internal OpenClaw/subagent context and inter-session messages.

There can be many of these entries, enough to fill most of the project sidebar.

Archive problem

Some of these internal-looking conversations can be archived, but others fail with an "archive failed" message.

Restarting Codex Desktop does not remove them.

This makes the sidebar difficult to use because internal implementation/session details are mixed with the conversations that I intentionally created.

Steps to reproduce

1. Open a Codex Desktop project connected to an OpenClaw workflow.
2. Use an existing normal Codex conversation.
3. Ask OpenClaw to perform work that causes a child session/subagent/session handoff.
4. Let the task complete.
5. Check the Codex project sidebar.

Actual result

Child/subagent/internal OpenClaw sessions appear as normal top-level user conversations in the sidebar.

Some entries also cannot be archived.

Expected result

Internal child sessions/subagent execution threads should either:

• remain hidden from the normal user conversation list, or
• be grouped under their parent conversation, or
• be clearly separated into an internal/agent activity section.

They should not appear as normal top-level user conversations mixed with manually created chats.

Completed internal sessions should also be safely removable/archiveable from the UI.

Additional information

I checked the OpenClaw side and confirmed that several of these entries correspond to completed child sessions and subagent work.

Examples included:

• session isolation tests
• read-only validation tasks
• pipeline recovery checks
• file path validation
• parent/child handoff tests

The underlying project files are not being duplicated; the main problem is the Codex Desktop sidebar/thread presentation and archive behavior.

I have already changed my OpenClaw delegation policy from prefer to suggest to reduce automatic session creation, but the UI issue remains relevant because valid subagent/session workflows can still produce these top-level sidebar conversations.

Please let me know if logs, session IDs, or additional reproduction information would be useful.

[ooocooc]

The current docs and protocol suggest a useful way to locate which side owns this bug.

The subagent documentation says subagent activity and threads are intentionally inspectable in the app, but that is different from presenting them as indistinguishable top-level user chats. In the current app-server schema, a native subagent thread has a non-null parentThreadId; it also exposes threadSource, whose kinds include subAgent, subAgentThreadSpawn, and related variants (Thread.ts, source kinds). thread/list also has a sourceKinds filter.

That gives a clean diagnostic split:

• if an affected entry has parentThreadId != null or a subAgent* source, but the sidebar still renders it as a top-level chat, this points to Codex client grouping/filtering;
• if it has parentThreadId = null and source appServer, OpenClaw likely created a normal top-level thread, and the title text alone is not enough for Codex to infer that it is internal.

For the archive failure, I would report it separately with only sanitized metadata: source kind, whether a parent ID exists, status, and the exact archive error—no prompt text or raw session ID required. Could you compare one archivable and one failing entry on those fields?