session.rpc.ui.elicitation() returns instant decline (1-2ms) without showing modal after sendAndWait

[Ofekw]

Environment

• Copilot CLI version: 1.0.36
• Extension SDK: @github/copilot-sdk/extension (joinSession API)
• OS: Windows 11 (Windows_NT)

Summary

When a Copilot CLI extension calls session.rpc.ui.elicitation() from inside a command handler that previously called session.sendAndWait(), the elicitation resolves with { action: "decline" } in 1-2ms without ever presenting a modal to the user. The session reports capabilities.ui.elicitation = true and mode = interactive, yet the user never sees any prompt.

The extension's agent-mediated fallback (sending a prompt asking the model to call ask_user) also fails because the ask_user tool auto-declines with "The user is not available to respond" for turns injected by sendAndWait.

Net result: The extension cannot collect any human input after delegating work via sendAndWait, making interactive gates (review finding selection, publish attestation) impossible.

Steps to reproduce

1. Load a Copilot CLI extension that registers a command via joinSession({ commands: [...] })
2. In the command handler, call session.sendAndWait() to delegate to another command
3. After sendAndWait resolves, call session.rpc.ui.elicitation() with a valid schema
4. Observe that it resolves instantly with { action: "decline" } --- no UI is shown

Minimal reproduction

import { joinSession } from "@github/copilot-sdk/extension";

const session = await joinSession({
  commands: [
    {
      name: "test-elicit",
      description: "Test elicitation after sendAndWait",
      handler: async (context) => {
        // Step 1: Delegate work to the model
        await session.sendAndWait({ prompt: "Say hello" }, 60_000);

        // Step 2: Try to elicit user input
        const start = Date.now();
        const result = await session.rpc.ui.elicitation({
          message: "Pick an option",
          requestedSchema: {
            type: "object",
            properties: {
              choice: {
                type: "string",
                title: "Your choice",
                enum: ["A", "B", "C"],
                default: "A",
              },
            },
            required: ["choice"],
          },
        });
        const elapsed = Date.now() - start;

        // Logs: "Elicitation returned decline in 1ms"
        await session.log(
          Elicitation returned {result.action} in {elapsed}ms
        );
      },
    },
  ],
});

Observed behavior

Timeline from session events

T+0s    session.info    "interactive elicitation: available; session mode: unknown"
        <- session.capabilities.ui.elicitation reports true

T+997s  sendAndWait("/review ...") called, completes successfully

T+997s  session.rpc.mode.set({ mode: "interactive" }) succeeds
        <- mode is now "interactive"

T+997s  session.rpc.ui.elicitation() called
        <- returns { action: "decline" } in 1ms
        <- NO MODAL IS SHOWN TO THE USER

T+997s  Agent-mediated fallback: sendAndWait() with prompt asking model to call ask_user
        <- model calls ask_user
        <- ask_user returns: "The user is not available to respond"
        <- model returns {"action":"decline"}

T+1024s Second elicitation attempt (text fallback)
        <- session.rpc.ui.elicitation() returns decline in 2ms (again, no modal)
        <- agent-mediated fallback also fails with "user not available"

Raw session event evidence

{
  "type": "session.warning",
  "data": {
    "message": "Direct elicitation returned decline in 1ms (mode: interactive); treating as synthetic decline."
  },
  "timestamp": "2026-04-27T03:00:07.856Z"
}

{
  "type": "tool.execution_complete",
  "data": {
    "toolTelemetry": {
      "properties": {
        "elicitation_action": "decline",
        "elicitation_field_types": "[\"multi-enum\",\"string\"]"
      }
    },
    "result": {
      "content": "The user is not available to respond and will review your work later."
    }
  },
  "timestamp": "2026-04-27T03:00:31.300Z"
}

Expected behavior

session.rpc.ui.elicitation() should present an interactive modal to the user and block until the user accepts, declines, or cancels. If the host cannot present a modal in the current execution context (e.g., inside a sendAndWait callback), it should either:

1. Queue the elicitation and present it after the current turn completes, or
2. Throw an error with a clear message like "Elicitation not supported during sendAndWait callbacks", or
3. Return a distinct result (e.g., { action: "unavailable" }) so extensions can distinguish "host can't show UI" from "user clicked decline"

Additionally, ask_user should work for model turns injected by extensions via sendAndWait. The user IS present --- they typed a command and are waiting. The sendAndWait turn is extension-initiated, but the session is still interactive.

Call context where elicitation fails

User types: /submit-pr
  -> handleSubmitPr()
    -> runPreflight()                          <- works
    -> sendAndWait("/review ...")              <- works (30min timeout)
    -> recordAndLogReviewOutput()              <- works
    -> askForReviewDecisions()                 <- FAILS HERE
      -> elicit(message, schema)
        -> session.rpc.ui.elicitation()        <- returns decline in 1ms
        -> agentMediatedElicitation()
          -> sendAndWait(prompt)               <- model calls ask_user
            -> ask_user                        <- "user not available"

Extension workaround code (currently failing)

async function elicit(message, requestedSchema) {
  if (!session.capabilities?.ui?.elicitation) {
    return agentMediatedElicitation(message, requestedSchema, "unavailable");
  }

  const mode = await ensureInteractiveMode(message);
  if (mode === "autopilot") {
    return agentMediatedElicitation(message, requestedSchema, "autopilot");
  }

  const elicitStart = Date.now();
  const result = await session.rpc.ui.elicitation({ message, requestedSchema });
  const elicitMs = Date.now() - elicitStart;

  // Detect synthetic decline (returned too fast for human interaction)
  const isSyntheticDecline =
    result.action === "decline" &&
    (["autopilot", "unknown"].includes(await refreshSessionMode())
     || elicitMs < 2000);

  if (isSyntheticDecline) {
    return agentMediatedElicitation(message, requestedSchema,
      �licitation-returned-in-{elicitMs}ms);
  }

  return result;
}

async function agentMediatedElicitation(message, requestedSchema, reason) {
  // Asks the model to call ask_user on behalf of the extension
  // FAILS: ask_user auto-declines for sendAndWait-injected turns
  const response = await sendAndCaptureContent(
    agentElicitationPrompt(message, requestedSchema, reason),
    15 * 60 * 1000
  );
  // ...parse JSON response...
}

Both layers fail:

• Layer 1 fails because session.rpc.ui.elicitation() returns decline in 1ms
• Layer 2 fails because ask_user auto-declines for turns injected by sendAndWait

Impact

• Extensions cannot implement interactive multi-step workflows
• session.capabilities.ui.elicitation capability check is misleading --- reports true but doesn't work in practice
• Extensions requiring human-in-the-loop gates (security attestation, publish confirmation) cannot enforce them
• The sendAndWait -> elicit pattern is the most natural way to build multi-step extension workflows, and it's completely broken

[github-actions]

Investigation Findings

Thanks for the detailed report, @Ofekw. I investigated the relevant SDK code and documentation to understand this behavior.

What I looked at

• nodejs/src/session.ts — sendAndWait, _executeCommandAndRespond, _elicitation, and related methods
• nodejs/src/extension.ts — joinSession implementation
• nodejs/README.md — UI Elicitation section and sendAndWait docs
• docs/features/ — streaming events and related feature docs

What I found

The SDK code is working as designed. When you call session.rpc.ui.elicitation() (or session.ui.elicitation()), the SDK checks the capability flag, then forwards the request to the Copilot CLI server via JSON-RPC and returns whatever the CLI responds with. The instant { action: "decline" } is the CLI server's response — the SDK is faithfully passing it through.

The CLI server treats turns programmatically initiated via sendAndWait (from an extension command handler) as non-interactive. In this context, the CLI does not present UI to the user and auto-declines elicitation requests. The same applies to ask_user — the "The user is not available to respond" message is the CLI server's decision, not the SDK's.

The documentation gap

This is a documentation issue. The current docs have two specific gaps that directly led to this problem:

1. session.capabilities.ui?.elicitation is documented as the definitive gate for elicitation, but it only reflects whether the host has elicitation infrastructure — it does not reflect whether the current execution context allows elicitation. The docs say:

   "Elicitation is only available when at least one connected participant advertises support. Always check session.capabilities.ui?.elicitation before calling UI methods."

   This is necessary but not sufficient. The docs should warn that capabilities.ui.elicitation = true does not guarantee elicitation will succeed — the CLI may still return { action: "decline" } in certain contexts (specifically from extension command handlers after sendAndWait).

2. The sendAndWait + elicitation pattern in extension command handlers is completely undocumented. The docs show many examples of sendAndWait for delegating work to the model, and separately show elicitation examples, but nowhere is it documented that combining them in a command handler context has constraints. The joinSession and command handler docs say nothing about which UI operations are available from within a handler.

What documentation should be added

• The UI Elicitation section should note that { action: "decline" } can be either a user-chosen decline or a system-generated decline (when the CLI cannot present UI in the current context), and that callers should design for both cases.
• The extension/joinSession command handler docs should document that elicitation is not available from within a command handler that has called sendAndWait, because the CLI treats extension-initiated agent turns as non-interactive.
• A note on sendAndWait that calling session.ui.elicitation() after sendAndWait in a command handler will result in an auto-decline.

Reclassification

Reclassifying as documentation. The product behavior is intentional (the CLI doesn't allow UI modals during programmatic/extension-initiated turns), but the SDK docs fail to communicate this constraint, which makes it impossible for extension authors to discover the limitation without filing a bug. Adding clear documentation about this context dependency would prevent this class of issue.

Generated by Bug Handler for issue #1149 · ● 780K · ◷

[Ofekw]

Thanks for the quick triage! A few follow-ups based on what we learned.

The mode.set puzzle

We actually tried to work around this — before calling elicitation(), the extension calls session.rpc.mode.set({ mode: "interactive" }), and it succeeds. The session mode is confirmed interactive in our logs. But elicitation still comes back in 1ms with a decline.

From the session events:

T+997.838s  "Switching session mode from autopilot to interactive"   ← ✅ worked
T+997.856s  "Direct elicitation returned decline in 1ms (mode: interactive)"  ← ❌ still auto-declined

So the session mode flag and the turn-level interactivity are two different things. mode.set changes the session flag, but it can't upgrade the current turn — the CLI has already tagged it as programmatic because it originated from sendAndWait. Makes sense once you know it, but it's really surprising when you're debugging it.

The practical problem

Our extension runs a multi-step workflow: preflight checks → delegate /review via sendAndWait → ask the user which findings to fix → delegate fixes → ask for publish attestation → publish.

Every user interaction after the first sendAndWait is dead. Both elicitation() and the ask_user fallback (via a second sendAndWait) auto-decline. The user never sees anything.

Right now our only workaround is to bail out of the command handler after each step and tell the user to re-run /submit-pr. It works (the state machine resumes), but it's clunky — the user has to keep re-invoking the command instead of getting a smooth guided flow.

What would help us / Feature Request

In rough priority order:

1. Distinguish auto-decline from user decline — even just { action: "decline", synthetic: true } or a different action string would let us handle it cleanly instead of using a timing heuristic (elicitMs < 2000).

2. A way to break out of the programmatic turn for user input — something like session.rpc.ui.requestInteraction() that pauses, presents UI, and resumes. This would make interactive multi-step extensions actually viable.

3. Docs for the sendAndWait + elicitation constraint — we spent a while debugging this. A note in the sendAndWait docs or the elicitation section saying "elicitation is not available from turns initiated by sendAndWait" would save others the same trip.

Happy to help implement and test any of this if there is rough guidance on the best approach here.