Claude Code - Skip run_tool HITL elicitation in bypassPermissions mode

[eshwar-sundar-glean]

What

When Claude Code is launched with --dangerously-skip-permissions (permission_mode: "bypassPermissions"), the user has opted out of every approval prompt for the session. The plugin's own HITL elicitation popup is then a redundant second gate — and, worse, when that elicitation times out it currently blocks the run_tool call entirely.

This change makes the plugin skip its elicitation gate and execute directly when — and only when — the session is in bypassPermissions mode. Scoped deliberately to run_tool and to bypassPermissions alone.

Why it needs a hook → server handoff

The elicitation popup is fired by the MCP server (handleRunTool → mcpServer.elicitInput), but the live permission mode is only visible to the PreToolUse hook (via its stdin permission_mode field). There is no env var or MCP initialize field that carries the permission mode to the server, and the mode can change mid-session — so the hook is the only channel.

How

• plugins/glean/hooks/auto-approve-run-tool.mjs — on every glean run_tool call (while ENABLE_HITL is on), writes { permission_mode, ts } to <CLAUDE_PLUGIN_DATA|~/.glean>/glean-hitl-mode/<sessionId>.json. Best-effort; a write failure never affects the existing auto-approve decision.
• src/tools/run-tool.ts — before eliciting, reads that per-session marker; if the mode is bypassPermissions, skips the popup and calls the tool directly.

The base dir + session-id sanitization are kept in lockstep across the hook, run-tool.ts, and start.sh's PLUGIN_DATA_DIR export.

Safety

• Ordering: PreToolUse strictly precedes the tool call, so the marker is always fresh for the call being gated.
• Resume: a session first launched with --dangerously-skip-permissions and later resumed without it (same session id) has its leftover bypassPermissions marker overwritten with the resumed mode by the hook on the resumed session's first run_tool call — before the server reads it — so the gate re-engages. No stale-marker leak across resume.
• Fail-safe: a missing / malformed marker, or a session-id mismatch, resolves to "unknown" → the gate is kept (fails toward prompting, never toward a silent bypass).
• Session-keyed: a bypass in one session can't suppress prompts in another concurrent session.

Testing

• npm run typecheck — clean
• npm test — 179 pass, incl. server cases (bypass skips elicit; default / absent / other-session all still elicit) and hook cases (marker written / session-keyed / sanitized; overwrites a leftover bypass marker on resume; nothing written when HITL off, non-glean, or mode absent).
• npm run build — dist/index.js rebuilt.

Verification still worth doing end-to-end

Two assumptions the implementation is safe against but that confirm the feature actually fires:

1. PreToolUse hooks run under --dangerously-skip-permissions (strongly implied by the docs; bypassPermissions is a documented hook permission_mode value).
2. The hook's session_id equals the CLAUDE_CODE_SESSION_ID that start.sh feeds the server as GLEAN_SESSION_ID.

Both are confirmed by running once with the flag and checking that a marker lands under ~/.glean/glean-hitl-mode/.

[swarup-padhi-glean]

Curious why we store a timestamp field in the marker

[eshwar-sundar-glean]

For now this is clean because this is only applicable to claude and cursor is not regressed because of this