fix: preserve cwd when forwarding reserved rescue job ids

[WoojinAhn]

Problem

When using the cc:rescue skill through the built-in forwarding child path, a reserved task job id can fail with:

Claude Code job id task-... is not reserved. Reserve one with the companion reserve-job helper before reusing it

In my session, background-routing-context --kind task --json returned a non-empty jobId, but forwarding that --job-id to claude-companion.mjs task from the spawned child failed with the message above. Running the same rescue flow without --job-id succeeded.

Likely Cause

The reservation appears to be workspace-scoped.

Relevant local behavior:

• background-routing-context resolves cwd via resolveCommandCwd()
• it resolves workspace via resolveCommandWorkspace({ cwd })
• it writes the reservation under resolveJobsDir(workspaceRoot)
• task --job-id validates the id by checking for the same reservation file under the workspace resolved from its own cwd

The current rescue skill guidance says to call:

node "<plugin-root>/scripts/claude-companion.mjs" background-routing-context --kind task --json

and then pass the returned --job-id into the companion task command.

However, it does not explicitly require the forwarding child to run from the same cwd, nor does it require passing --cwd <original-workspace-cwd> into both the routing-context call and the final task call. If the built-in child starts in a different cwd, the reservation lookup uses a different workspace hash and fails.

Reproduction

From a Codex session using the cc:rescue skill:

1. Run the rescue skill path that captures routing context:

node "<plugin-root>/scripts/claude-companion.mjs" background-routing-context --kind task --json

2. Use the returned jobId in the spawned forwarding child command:

node "<plugin-root>/scripts/claude-companion.mjs" task --job-id <returned-job-id> --view-state on-success "<task>"

3. If the child process resolves a different cwd/workspace than the parent, the command fails:

Claude Code job id <returned-job-id> is not reserved. Reserve one with the companion reserve-job helper before reusing it

4. Running without --job-id can still succeed, which suggests the task path works but the reserved-id validation is losing workspace identity.

Expected Behavior

The built-in rescue forwarding path should preserve the workspace used to reserve the job id.

Possible fixes:

• Update the rescue skill instructions to capture the original cwd and pass --cwd <cwd> consistently to both:
  • background-routing-context --kind task --cwd <cwd> --json
  • task --cwd <cwd> --job-id <reserved-job-id> ...
• Or make background-routing-context return the resolved workspace/cwd that must be forwarded with the job id.
• Or make the companion command provide a clearer diagnostic when the reservation exists under a different workspace hash.

Acceptance

• A reserved jobId returned by background-routing-context works when forwarded through the built-in rescue child.
• The rescue skill documentation explicitly preserves cwd/workspace identity for reserved job ids.
• The failure message or debug output makes cwd/workspace mismatch distinguishable from an actually missing reservation.

[sf-jin-ku]

Resolved and released in v1.3.0 via PR #75. The built-in rescue/review/adversarial-review forwarding paths now pass the routing helper’s originating workspace as an explicit --cwd whenever they forward a reserved --job-id. Contract regressions cover all three child commands. Release: https://github.com/sendbird/cc-plugin-codex/releases/tag/v1.3.0