Run any Skill in Manus with one click

ghostex-move-codex-session

Stars625

Forks31

UpdatedJune 27, 2026 at 09:11

Explain how to fork an existing Codex CLI session into another folder by using `/status` to get the session id and `codex fork --yolo -C TARGET_FOLDER SESSION_ID`. Use when a user asks to move the current Codex session, change the Codex working directory, fork a Codex conversation into a different project folder, or continue a Codex thread under another workspace root as a separate session.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

maddada

maddada/Ghostex

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Computer Occupations, All OtherComputer and Mathematical Occupations·SOC 15-1299

File Explorer

2 files

SKILL.md

readonly

name	ghostex-move-codex-session
description	Explain how to fork an existing Codex CLI session into another folder by using `/status` to get the session id and `codex fork --yolo -C TARGET_FOLDER SESSION_ID`. Use when a user asks to move the current Codex session, change the Codex working directory, fork a Codex conversation into a different project folder, or continue a Codex thread under another workspace root as a separate session.

ghostex-move-codex-session

Explain the supported Codex CLI workflow in simple numbered steps.

Steps

Ask the user to run this inside the current Codex session:
```
/status
```
Tell the user to copy the session id shown by /status.
Tell the user to open a shell and fork that session in the target folder:
```
codex fork --yolo -C ~/dev/hackathon <SESSION_ID>
```

Replace ~/dev/hackathon with the requested folder when the user gave a different target.

Tell the user that --yolo is the Codex alias for bypassing approvals and sandboxing. If they do not want full access, remove --yolo.

Fallback

If the user does not want to copy the id, suggest the recent-session fallback:

codex fork --all --last --yolo -C ~/dev/hackathon

Explain that --all matters because Codex normally filters fork candidates by the current working directory.

Rules

Keep the answer short and procedural.
Prefer codex fork --yolo -C <folder-path> <SESSION_ID> as the primary command.
Mention that this creates a separate forked Codex session under the new working root.
Mention that users can remove --yolo if they do not want full-access mode.
Do not claim the active running TUI can be moved in place unless current Codex docs expose a real command for that.
If the user asks for the exact command only, give only the command and one sentence.

More from this repository

same repository

ghostex-fable-5-5-orchestration

maddada/Ghostex

Use this skill to execute a multi-phase coding task with a Fable-planned, Codex-implemented, Fable-verified pipeline inside Ghostex: the invoking session plans inline and writes a phase plan file, launches one Codex (gpt-5.5) worker pane per phase through the Ghostex CLI, then launches a Fable verifier pane that checks every acceptance criterion, and spawns targeted Codex fixer panes for any findings until verification passes or the fix loop cap is reached.

2026-07-07625

ghostex-agent-orchestration

maddada/Ghostex

Use this skill when coordinating work across Ghostex panes or agent sessions through the Ghostex CLI: creating terminal or agent panes, listing sessions, checking agent status, sending messages to other agent sessions, reading the last lines from another session, focusing/sleeping/waking/killing sessions, or using Ghostex commands instead of raw zmx/tmux control.

2026-07-04625

ghostex-generate-title

maddada/Ghostex

Generate a concise Ghostex session title for the current thread or conversation. Use when the user asks for a thread name, chat title, session title, resume title, or any concise label summarizing what was worked on; then submit the rename command in the current Ghostex session.

2026-07-04625

herdr

maddada/Ghostex

Control herdr from inside it. Manage workspaces and tabs, split panes, spawn agents, read output, and wait for state changes — all via CLI commands that talk to the running herdr instance over a local unix socket. Use when running inside herdr (HERDR_ENV=1).

2026-07-02625

ghostex-browser-use

maddada/Ghostex

Use this skill when adding, configuring, or troubleshooting agent access to Ghostex embedded CEF browser panes through the Ghostex Browser Use MCP workflow. It covers CLI installation, MCP config, page selection, console logs, DOM snapshots, clicks, fills, key presses, screenshots, and the CEF remote debugging port used by `ghostex browser mcp`.

2026-06-19625

ghostex-computer-use

maddada/Ghostex

Use this skill when the user asks for Ghostex Computer Use, Desktop Control, or native macOS app automation. It wraps the Cua Driver workflow so agents can drive desktop apps without the user needing to remember `$cua-driver`.

2026-06-19625

name	ghostex-move-codex-session
description	Explain how to fork an existing Codex CLI session into another folder by using `/status` to get the session id and `codex fork --yolo -C TARGET_FOLDER SESSION_ID`. Use when a user asks to move the current Codex session, change the Codex working directory, fork a Codex conversation into a different project folder, or continue a Codex thread under another workspace root as a separate session.

ghostex-move-codex-session

Explain the supported Codex CLI workflow in simple numbered steps.

Steps

Ask the user to run this inside the current Codex session:
```
/status
```
Tell the user to copy the session id shown by /status.
Tell the user to open a shell and fork that session in the target folder:
```
codex fork --yolo -C ~/dev/hackathon <SESSION_ID>
```

Replace ~/dev/hackathon with the requested folder when the user gave a different target.

Tell the user that --yolo is the Codex alias for bypassing approvals and sandboxing. If they do not want full access, remove --yolo.

Fallback

If the user does not want to copy the id, suggest the recent-session fallback:

codex fork --all --last --yolo -C ~/dev/hackathon

Explain that --all matters because Codex normally filters fork candidates by the current working directory.

Rules

Keep the answer short and procedural.
Prefer codex fork --yolo -C <folder-path> <SESSION_ID> as the primary command.
Mention that this creates a separate forked Codex session under the new working root.
Mention that users can remove --yolo if they do not want full-access mode.
Do not claim the active running TUI can be moved in place unless current Codex docs expose a real command for that.
If the user asks for the exact command only, give only the command and one sentence.