ce-sessions: pre-resolved repo-name uses $(…) command substitution, blocked by Claude Code permission check (sibling of #795)

[mrvdot]

Bug Description

Component: Skill — ce-sessions
Summary: Invoking ce-sessions fails immediately because the pre-resolved "Repo name" line uses $(...) command substitution inside a !-prefixed bash inline. Claude Code's permission system refuses to statically analyze it and aborts before any Phase 1 work begins.

This is the same family of bug as #795 (which I filed for ce-compound's git ... | sed pattern) but a different specific permission rule trips. #795 was the multi-operation check; this is the static-analysis check. The fix for ce-compound in v3.7.3 was to drop the offending line entirely, which works. ce-sessions instead adopted Option A from my own suggested fixes in #795 — basename "$(git rev-parse --show-toplevel)" — and that adoption tripped a sibling permission rule.

Environment

• Plugin Version: compound-engineering 3.8.0 (from every-marketplace, current)
• Agent Platform: Claude Code
• OS: Darwin 25.5.0 (macOS)
• Working dir: inside a normal git worktree (git rev-parse would succeed)

What Happened

When ce-sessions is invoked (in my case via the Skill tool from inside ce-compound Phase 1):

Error: Shell command permission check failed for pattern
"!`basename "$(git rev-parse --show-toplevel 2>/dev/null)" 2>/dev/null || true`":
Contains shell syntax (string) that cannot be statically analyzed

The skill never executes. The companion line right above (git rev-parse --abbrev-ref HEAD) works fine — it has no $(...) substitution.

Root Cause

plugins/compound-engineering/skills/ce-sessions/SKILL.md lines 17-23:

## Pre-resolved context

**Git branch (pre-resolved):** !`git rev-parse --abbrev-ref HEAD 2>/dev/null || true`

If the line above resolved to a plain branch name (like `feat/my-branch`), use it for branch filtering and pass it to the synthesis subagent. If it still contains a backtick command string or is empty, derive the branch at runtime instead.

**Repo name (pre-resolved):** !`basename "$(git rev-parse --show-toplevel 2>/dev/null)" 2>/dev/null || true`

Claude Code's bash permission layer cannot statically analyze the $(...) substitution. Even with broad git permissions allowlisted, the substitution shape itself is what's rejected — it's not a missing-allow-rule issue.

Suggested Fix

Use Option B from #795 — emit the toplevel path verbatim, let the dispatcher take the basename:

-**Repo name (pre-resolved):** !`basename "$(git rev-parse --show-toplevel 2>/dev/null)" 2>/dev/null || true`
+**Repo toplevel (pre-resolved):** !`git rev-parse --show-toplevel 2>/dev/null || true`

Then update the "If the line above resolved..." sentence to tell the dispatcher: "If the line above resolved to a plain absolute path like /Users/me/code/myrepo, take its basename and use that for session discovery. Otherwise derive at runtime."

This avoids both $(...) substitution and | pipes — the agent does the trivial string slice.

ce-compound 3.7.3 took an even simpler path: drop the pre-resolved repo-name line entirely and rely on runtime derivation. That also works, and is probably the right call here too if the repo-name pre-resolution isn't load-bearing for ce-sessions's discovery flow.

Repro

1. Open Claude Code in any git worktree.
2. Invoke ce-sessions (directly via Skill tool, via /ce-compound Phase 1 with session history opted in, or via any other caller).
3. Observe the Shell command permission check failed ... Contains shell syntax (string) that cannot be statically analyzed error before the skill enters its main flow.

Additional Context

This blocked the session-history phase of /ce-compound for me today (3.8.0 cache, plugin auto-updated and reloaded). I worked around it by proceeding without session context. The fix should be a one-line edit in ce-sessions/SKILL.md.

Cross-referencing: #795 (the parent issue, originally about ce-compound's | sed chain), #730 (different — about being outside a git repo).