Add subproject/workspace organization under a single SSH host project

Summary

When Codex is connected to an SSH host, the host effectively becomes one broad project umbrella. That works for a single repository, but it breaks down when the remote SSH host is a real development server containing many independent repositories/projects at the same time.

There does not appear to be a way to organize nested subprojects under the same SSH connection. As a result, unrelated sessions from unrelated repos all appear under the same SSH project, making the project/thread list hard to navigate and easy to mix up.

Environment

• Product surface: Codex App / IDE extension with SSH remote project support
• Local workstation: Windows
• Remote host: Linux over SSH
• Remote Codex CLI observed in the SSH environment: codex-cli 0.134.0
• Remote OS observed: Linux 5.15.0-173-generic x86_64

Current behavior

The SSH connection is treated as the project-level container. If the remote host contains multiple active projects, Codex does not provide a first-class way to split the SSH project into subprojects by remote path, Git repository, workspace root, or user-defined label.

A concrete local/remote state example from my SSH environment:

source=vscode threads: 413
threads with cwd=/root: 404
threads with cwd=/root/.openclaw/workspace: 8
threads with cwd=/root/.openclaw/workspace-trader: 1

Those /root threads are not all one project in practice. They include work for different repos/products under the same SSH host, such as tasks that start with prompts like no vorax, no new-omnia-latest, and other remote workspace aliases. The UI grouping still collapses them under the same SSH/project umbrella.

Why this matters

A single SSH host is often a workspace server, not a single project. It may contain:

• multiple unrelated repos
• multiple clients/products
• temporary worktrees
• production and staging toolchains
• long-running agent sessions for different codebases

Without subproject grouping, the sidebar/project history becomes noisy. It is harder to find the right session, harder to avoid starting a task in the wrong context, and harder to reason about which threads belong to which repo.

Expected behavior

Codex should support first-class subprojects/workspaces inside one SSH host/project.

Useful behavior would include:

• The SSH host remains the top-level connection.
• Under that host, users can define or discover subprojects by remote path and/or Git repository root.
• Thread lists can be filtered/grouped by subproject.
• Starting a new thread can choose a specific subproject, setting the correct remote cwd.
• Subprojects can have labels, ordering, pinning, and archived/hidden state independently of the host.
• Codex can infer a default subproject from cwd, Git root, or explicit user selection, but users should also be able to manually define subprojects when they intentionally start from a shared directory like /root.

Example UI shape:

SSH: prod-devbox
  /root/.openclaw/workspace-trader/repos/vorax-trader
  /root/.openclaw/workspace-digithag/repos/smartclean
  /root/new-omnia-latest

Actual behavior

The remote SSH connection behaves like one flat project. Multiple real projects and their threads are interleaved under the same umbrella, even when the work belongs to different remote repos.

Related context

This is adjacent to remote/DevBox-first workflow requests like #23907, but the request here is narrower: once an SSH host is already connected and working, Codex needs a way to organize multiple subprojects inside that one remote host.