AskUserQuestion is always denied by the PreToolUse hook, while every other tool passes (CodeIsland 1.0.33, Claude Code 2.1.261)

[seahindeniz]

Summary

With CodeIsland's global PreToolUse hook installed, every AskUserQuestion call from Claude Code is rejected with Permission denied by hook. Every other tool in the same session passes normally, so this is not a blanket silencing — it is specific to AskUserQuestion.

No question card is usable, so the agent cannot ask the user anything for the whole session.

Environment

CodeIsland	1.0.33
Claude Code	2.1.261
macOS	26.6.1 (25G76), Apple Silicon
Hook	~/.claude/settings.json → PreToolUse, matcher "" → ~/.codeisland/codeisland-hook.sh → execs ~/.codeisland/codeisland-bridge

Steps to reproduce

1. Install CodeIsland so the global catch-all PreToolUse hook is present.
2. In a Claude Code session, have the agent call AskUserQuestion.
3. The call returns Permission denied by hook.

What I observed

• 6 attempts over ~40 minutes, all denied.
• Not payload-shape dependent. Denied both for a rich payload (2 questions, options carrying preview blocks) and for a minimal one (1 question, 2 options, no previews).
• Only this tool. Bash, Write, Edit, subagent dispatch and several MCP tools all ran normally in the same session, before and after each denial.
• Isolated to the CodeIsland hook by elimination. The project also had its own PreToolUse hook matching AskUserQuestion, but it only ran afplay …/Pop.aiff & — verified exit code 0 with and without the &, so it cannot deny. Removing it entirely changed nothing; the denial persisted. The CodeIsland catch-all is then the only remaining hook able to return a deny decision.

What I could not reproduce from outside the app

These may help narrow it down — the deny does not appear to live in the shell layer:

• Piping a synthetic PreToolUse payload for AskUserQuestion to ~/.codeisland/codeisland-bridge produces no output and exit 0.
• Piping the same payload to /tmp/codeisland-<uid>.sock returns {}.
• The identical probe for Bash also returns {} — the socket layer does not distinguish the two tools.

So the decision seems to depend on live session state that a synthetic session_id does not match, i.e. it is inside the bridge/app rather than in codeisland-hook.sh.

Expected

AskUserQuestion should be surfaced as a question card, or passed through if CodeIsland does not handle it — but not denied.

Possibly related

• AskUserQuestion selection crashes with 'undefined is not an object (evaluating H.map)' #157 — AskUserQuestion selection crashes with undefined is not an object (evaluating H.map)
• Question and permission panel becomes invisible after around 2s on some screens #304 — Question and permission panel becomes invisible after ~2s on some screens
• Dismissing an approval card silences every later permission request, from all sessions #309 — Dismissing an approval card silences every later permission request (closed; distinguished here because only AskUserQuestion is affected, not every tool)

Note

The shell fallback path in codeisland-hook.sh (used when the bridge binary is absent) pipes the payload through nc -U, and nc writes the socket's reply to stdout — which Claude Code parses as the hook's decision. That path is not what produced this bug on my machine (the bridge binary is present, so the script execs it), but it looks like a route by which an unexpected daemon reply could become an unintended hook decision. Flagging it in case it is useful.

[seahindeniz]

Confirmed and isolated: disabling hooks in the CodeIsland app resolves it — AskUserQuestion works again immediately, with no change to Claude Code or to any project-level configuration.

So the denial is produced by CodeIsland's hook integration, not by Claude Code or the shell wrapper. That also gives anyone else hitting this a workaround in the meantime: turn hooks off in the app, at the cost of losing CodeIsland's status/approval integration.