[FEATURE] Let another local process see and answer a running session's pending permission prompt

Status Open
Reported on v2.1.289
Maintainer reply None cached
Activity 1 comment · opened Oct 6, 2026

Problem

A tool that drives Claude Code sessions on the same machine (an orchestrator, a
dashboard, a phone relay) can find a session that is stuck on a permission
prompt, but cannot see what it is asking or answer it, unless a hook was
installed before the session started. For sessions the Claude desktop app runs,
the prompt only goes to the app's own pipe.

What we observed (CLI 2.1.289, macOS, 2026-10-06)

We started a session the way the desktop app does
(--input-format stream-json --output-format stream-json --permission-prompt-tool stdio --permission-mode default)
and asked it to Write a file, then left the can_use_tool request unanswered.

  1. claude agents --json reports "status": "waiting", "waitingFor": "permission prompt".

It does not say which tool, which input, or the request id.

  1. The transcript JSONL has the tool_use block and no tool_result. An

outside reader can guess the pending call from that, but nothing ties it to
the prompt.

  1. Nothing outside the session's stdin can answer it. A cross-session message

from a session in the same permission mode is written as a
queue-operation: enqueue and waits; it does not answer or interrupt the
prompt. One from a different mode is held (peer_message_hold,
cause: mode-mismatch) and, with no terminal to approve it, expires.

  1. The request did not time out within 150 s.
  2. A PermissionRequest hook in --settings does answer it: the hook ran,

returned allow, the host received control_cancel_request for the
pending can_use_tool, and the tool ran. So the mechanism exists, but only
for a hook configured before the session started, and only as a
synchronous script.

sequenceDiagram
  participant Host as Host (desktop app / SDK)
  participant CC as claude process
  participant Hook as PermissionRequest hook
  participant Ext as Another local process
  CC->>Host: control_request can_use_tool (Write)
  Ext->>CC: claude agents --json
  CC-->>Ext: waiting, "permission prompt" (no tool, no input, no id)
  Ext->>CC: cross-session message
  Note over CC: enqueued, prompt still pending
  Note over Ext,CC: no way to answer from here
  CC->>Hook: only if configured at startup
  Hook-->>CC: allow
  CC->>Host: control_cancel_request
  Note over CC: tool runs

Ask

  • Put the pending request in claude agents --json (and the

~/.claude/sessions/<pid>.json record): request id, kind (permission or
question), tool name and input.

  • A supported way for another local process to answer it, for example

claude agents respond <session> <request-id> allow|deny [--message …], or
the same through the session's messaging socket, subject to the same
permission rules as the session's own user.

Related: #85192 (expose waiting state), #94620 (list sessions and state),
#97911 (unattended --bg prompts hang unseen), #88698 (PermissionRequest hook
decisions discarded in --bg), #89182 (act while a prompt is pending over
Remote Control).

---
_Generated by Claude Code (Opus 5.5, medium effort)._

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗