[BUG] ask_user answered from main session (while question from subagent) consumes 1 premium request

[bizzkoot]

Bug Report

Summary

When a subagent calls the ask_user tool and the user answers while viewing the MAIN session (not navigated to the subagent session), 1 premium request is consumed. However, if the user navigates directly to the subagent session before answering, no premium is consumed.

Expected Behavior

• Subagent calls ask_user tool
• User answers the question from ANY session view (main or subagent)
• Answer is delivered via IPC to the waiting subagent
• NO additional premium request should be consumed

Actual Behavior

• Scenario A (Working): User navigates to subagent session, answers ask_user → No premium consumed ✅
• Scenario B (BUG): User stays in main session, answers ask_user from subagent → 1 premium consumed ❌

Environment

• CodeNomad version: latest
• Platform: All (Electron app)

Steps to Reproduce

1. Send a prompt that triggers a subagent
2. The subagent calls ask_user to ask a question
3. Stay in the main session (do NOT navigate to the subagent session)
4. Answer the question in the UI
5. Observe that the premium request count increases by 1 ❌

Root Cause Analysis

Key Observation: When the user answers while viewing the MAIN session, the answer is being routed incorrectly.

Hypothesis: Session association issue

• When answering from main session view, the system may create a new user message in the MAIN session
• This triggers a new LLM request in the main session (premium consumed)
• The answer is NOT being properly routed via IPC to the waiting subagent

What should happen:

// Current flow when answering from main session:
User answers (in main session view)
  ↓
Creates user message in MAIN session ❌
  ↓
Triggers LLM request in MAIN session ❌
  ↓
Premium consumed ❌

// Correct flow:
User answers (from any session view)
  ↓
Sends via mcp:answer IPC ✅
  ↓
Resolves subagent's ask_user Promise ✅
  ↓
No premium consumed ✅

Possible causes:

1. The question wizard may be creating a user message in the currently-viewed session instead of just sending IPC
2. The answer handler may not be routing correctly when the active session != the question's session
3. There may be session ID confusion in the answer routing logic

Relevant Files

• packages/ui/src/components/instance/instance-shell2.tsx (lines 280-343) - Answer submission handler
• packages/ui/src/stores/questions.ts - Question queue and session association
• packages/ui/src/lib/mcp-bridge.ts - MCP bridge implementation
• packages/mcp-server/src/bridge/ipc.ts - IPC handlers

Investigation Needed

1. Check session association in question queue:

   • Verify that pending questions store their originating session ID
   • Check if the answer handler uses the question's session ID or the current active session ID

2. Trace the answer flow:

   • When answering from main session, what sessionId is associated with the answer?
   • Is a new user message created in the main session?

3. Compare the two scenarios:

   • Scenario A (working): Answer from subagent session view
   • Scenario B (broken): Answer from main session view
   • What's different in the code path?

Debug Steps

1. Enable dev mode and look for:

   • [✅ ANSWER SUBMIT] logs - check the instanceId and session info
   • [✅ ROUTING] Using MCP path vs [❌ ROUTING] Using OpenCode SDK path
   • Any logs showing user message creation on answer

2. Add logging to track:

   • Which session the question originated from
   • Which session is currently active when answering
   • Whether a user message is created in the main session

Priority

High - This significantly impacts UX when using subagents, as users must navigate away from the main conversation to avoid consuming premium

Related Issues

• [BUG] Subagent launches consume 1 premium request each #23: Subagent launches consume 1 premium request each

Labels

bug, premium, ask_user, subagent, routing, priority:high

[bizzkoot]

Deep Root Cause Analysis

After conducting an in-depth sequential analysis, I've identified the root cause of why answering ask_user from the main session (while question from subagent) consumes 1 premium request.

The Bug

Location: packages/ui/src/lib/mcp-bridge.ts (lines 261-262)
Related: packages/ui/src/components/instance/instance-shell2.tsx (line 733)

Root Cause: Question Routed to Wrong Instance Queue

The bug occurs because questions from subagents are being added to the main session's queue, not the subagent's queue.

Here's the problematic flow:

1. User views main session (instance A)
2. initMcpBridge(instanceA) is called, capturing instanceId = instanceA
3. Subagent (instance B) calls ask_user
4. ask_user.asked IPC event is sent from main process
5. IPC listener processes the event:

   const activeId = activeInstanceId(); // = instanceA (user is viewing main session)
   const instanceId = instanceA; // captured by closure from initMcpBridge
   const targetInstanceId = activeId ?? instanceId; // = instanceA
   // Question added to instance A's queue!

6. Question is in instance A's queue with source='mcp'
7. User answers from instance A
8. Answer is sent via MCP IPC (correct path, zero-cost)

So far, this should work correctly. But the issue reports that a premium request IS consumed. This suggests there's a second code path adding the question WITHOUT the source field.

The Second Code Path: OpenCode SSE Handler

Location: packages/ui/src/stores/instances.ts (lines 671-682)

sseManager.onQuestionAsked = (instanceId, event) => {
    if (event.properties) {
        addQuestionToQueue(instanceId, event.properties) // ❌ WITHOUT source field!
    }
}

This adds the question to the originating instance's queue (instance B) WITHOUT the source field!

The Result: Two Questions in Two Different Queues

• Instance A's queue (main): Question from MCP bridge (with source='mcp')
• Instance B's queue (subagent): Question from OpenCode SSE (WITHOUT source)

Why Scenario A Works (Navigating to Subagent Session)

When user navigates to instance B and answers:

1. Question is retrieved from instance B's queue
2. Question has NO source field (from OpenCode SSE)
3. Code checks if (question.source === 'mcp') → FALSE
4. Wait, this should use OpenCode SDK path (premium cost), but it doesn't!

This suggests the OpenCode SSE handler might NOT be firing for MCP ask_user calls (which is correct).

Why Scenario B Fails (Staying in Main Session)

There must be a duplicate listener scenario causing issues:

Multiple IPC Listeners Bug:

When initMcpBridge is called for multiple instances:

1. initMcpBridge(instanceA) attaches listener A (captures instanceId = instanceA)
2. initMcpBridge(instanceB) attaches listener B (captures instanceId = instanceB)
3. Both listeners process the SAME ask_user.asked IPC event!

When the subagent (instance B) calls ask_user:

• Listener A: targetInstanceId = activeId ?? instanceA = instanceA
• Listener B: targetInstanceId = activeId ?? instanceB = instanceA (since activeId = instanceA)

Both listeners try to add the question to instance A's queue!

The Fix

Option 1: Use Originating Instance ID from MCP IPC

Modify packages/mcp-server/src/bridge/ipc.ts to include the originating instance ID in the IPC payload:

mainWindow.webContents.send('ask_user.asked', {
    requestId,
    questions,
    title,
    source: 'mcp',
    originatingInstanceId: workspaceId // ✅ Include originating instance
});

Then modify packages/ui/src/lib/mcp-bridge.ts to use the originating instance ID:

const { requestId, questions, source, originatingInstanceId } = payload;
const targetInstanceId = originatingInstanceId ?? activeId ?? instanceId;

Option 2: Single Global IPC Listener

Refactor mcp-bridge.ts to use a SINGLE global IPC listener instead of per-instance listeners. This listener should:

• Track all active instances
• Always route questions to their originating instance
• Not capture instanceId in a closure

Option 3: Fix the Multiple Listener Issue

Prevent duplicate IPC listeners from being attached. Check if a listener already exists before attaching a new one.

Files to Modify

1. Primary: packages/ui/src/lib/mcp-bridge.ts (question routing logic)
2. Secondary: packages/mcp-server/src/bridge/ipc.ts (include originating instance ID)
3. Verify: packages/ui/src/components/instance/instance-shell2.tsx (initMcpBridge calls)

---

Analyzed via sequential-thinking deep dive

[bizzkoot]

Regression Risk Analysis & Diagnostic Approach

Root Cause: Unable to Identify from Static Analysis

After thorough code review, the implementation appears CORRECT:

• handleQuestionSubmit properly checks question.source === 'mcp'
• MCP questions route via IPC (zero cost)
• OpenCode questions route via API (premium)
• Source is properly passed through the chain

The Problem

Since the code is correct but the bug exists, the issue is likely:

1. MCP server not sending source field correctly
2. Wrong instance routing (question in wrong queue)
3. Subtle timing issue not visible in static analysis

Regression Risk of Fixes (Without Diagnosis): VERY HIGH

Shooting in the dark without knowing the actual bug could:

• Break the working scenario (answering from subagent session)
• Introduce new issues with question routing
• Cause message delivery failures

RECOMMENDED SOLUTION: Diagnose First

Add diagnostic logging BEFORE any fix:

// In instance-shell2.tsx, handleQuestionSubmit
const handleQuestionSubmit = async (answers: QuestionAnswer[]) => {
  const question = getPendingQuestion(props.instance.id)
  
  if (import.meta.env.DEV) {
    console.log('[🔍 ANSWER DEBUG]', {
      questionId: question?.id,
      source: question?.source,
      sourceType: typeof question?.source,
      hasSource: question?.source \!== undefined,
      sourceValue: question?.source === 'mcp' ? 'MCP (IPC)' : 'OpenCode (Premium)',
      instanceId: props.instance.id,
      willRouteMCP: question?.source === 'mcp'
    })
  }
  
  if (question.source === 'mcp') {
    console.log('[✅ Using MCP IPC path (zero cost)]')
  } else {
    console.log('[❌ Using OpenCode API path (PREMIUM)]', {
      actualSource: question.source,
      sourceType: typeof question.source
    })
  }
}

Testing Steps

1. Add the logging above
2. Test Scenario A (Working):
   • Navigate to subagent session
   • Answer ask_user question
   • Capture logs
3. Test Scenario B (Broken):
   • Stay in main session
   • Answer ask_user question
   • Capture logs
4. Compare the logs to identify what's different

Expected Findings

Log Field	If Different	Indicates
source	Different values	Source propagation bug
instanceId	Different values	Routing bug
hasSource	False in scenario B	MCP server not sending source
willRouteMCP	False in scenario B	Routing logic issue

Only After Diagnosis

Once we identify the actual difference, we can implement a targeted fix with:

• Clear understanding of what to change
• Minimal regression risk
• Specific test case to verify

Please add the diagnostic logging and share the results so we can identify the true root cause.