Windows/Codex: plan-eng-review inline office-hours path is not installed by setup #2449

Summary

After running the official Codex setup on Windows through Git Bash:

./setup --host codex --prefix

the generated gstack-plan-eng-review skill instructs Codex to inline-read office-hours from:

GSTACK_ROOT="$HOME/.codex/skills/gstack"
$GSTACK_ROOT/office-hours/SKILL.md

However, setup installs the skill at:

$HOME/.codex/skills/gstack-office-hours/SKILL.md

and does not create:

$HOME/.codex/skills/gstack/office-hours/SKILL.md

As a result, the official inline office-hours step in plan-eng-review points to a path that does not exist.

Environment

• Windows
• Git Bash
• Codex host
• gstack 1.60.1.0
• setup flags: --host codex --prefix

Reproduction

1. Run the official setup command above.
2. Check the installed paths:

test -f "$HOME/.codex/skills/gstack-office-hours/SKILL.md"   # succeeds
test -f "$HOME/.codex/skills/gstack/office-hours/SKILL.md"   # fails

3. Inspect the generated $HOME/.codex/skills/gstack-plan-eng-review/SKILL.md. It sets GSTACK_ROOT="$HOME/.codex/skills/gstack" and later reads $GSTACK_ROOT/office-hours/SKILL.md.

Source mismatch

In hosts/codex.ts, the Codex transform rewrites ~/.claude/skills/gstack to $GSTACK_ROOT. The Codex global runtime symlink list does not include office-hours. Meanwhile, setup exposes generated skills as top-level gstack-* directories under $HOME/.codex/skills.

Expected behavior

Either:

1. The generated parent skill should inline-read the actual installed gstack-office-hours/SKILL.md path, or
2. Setup should install/link office-hours under $GSTACK_ROOT/office-hours.

The important behavior is to preserve the documented inline execution inside plan-eng-review, rather than launching office-hours as a separate full skill.

Temporary workaround

A Windows directory Junction from:

$HOME/.codex/skills/gstack/office-hours

to:

$HOME/.codex/skills/gstack-office-hours

makes the inline read work, and the two SKILL.md files can be hash-verified as identical. This is only a local workaround because a future setup/upgrade may recreate the runtime root.