[BUG] RooCodeAPI Events Not Emitted When Using "Open in New Tab" Command

[nhjelle]

Problem (one or two sentences)

When Roo Code is opened in a new tab via the command palette (roo-cline.openInNewTab), events are not emitted through the RooCodeAPI EventEmitter. This prevents external extensions from receiving task events (taskCreated, message, taskCompleted, etc.) when users work in tab mode.

Context (who is affected and when)

This bug affects:

• Telemetry extensions that track task metrics
• Automation tools that respond to Roo Code events
• Integration extensions that need to know when tasks start/complete
• Any external tooling relying on the RooCodeAPI EventEmitter

Reproduction steps

1. Create an extension that listens to Roo Code events via the API:

   const rooCodeExtension = vscode.extensions.getExtension("RooVeterinaryInc.roo-cline")
   const api = rooCodeExtension.exports as RooCodeAPI
   
   api.on("taskCreated", (taskId) => {
     console.log("Task created:", taskId)
   })

2. Open Roo Code using "Open Roo Code in a new tab" command (via command palette)

3. Start a new task in the tab

Expected result

The taskCreated event should fire

Actual result

No events are emitted

Variations tried (optional)

Currently, users can:

1. Use the sidebar view instead of tab mode (events work correctly)
2. Start tasks programmatically via api.startNewTask({ newTab: true }) (events work correctly)

App Version

3.47.3

API Provider (optional)

None

Model Used (optional)

No response

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

After analyzing the source code, the issue is in how tab providers are created vs. how the API registers listeners:

### In `src/extension/api.ts`:

The API class has a `registerListeners()` method that forwards events from a `ClineProvider` to the API's EventEmitter:


private registerListeners(provider: ClineProvider) {
  provider.on(RooCodeEventName.TaskCreated, (taskId) => {
    this.emit(RooCodeEventName.TaskCreated, taskId)
  })
  // ... other event forwarding
}


### When opening via API (works correctly):

In `startNewTask()` with `newTab: true`:

// Line 185-186 in api.ts
provider = await openClineInNewTab({ context: this.context, outputChannel: this.outputChannel })
this.registerListeners(provider)  // ✅ Events are forwarded


### When opening via command (broken):

In `src/activate/registerCommands.ts`:

openInNewTab: () => openClineInNewTab({ context, outputChannel })
// ❌ registerListeners() is never called on the returned tabProvider


The `openClineInNewTab()` function creates a new `ClineProvider` and returns it, but when called from the command handler, the returned provider is discarded without registering event listeners.

The `sidebarProvider` correctly emits events because it's created during extension activation and passed to the API constructor. The issue is specifically with dynamically-created tab providers that bypass the API's event registration.

[roomote]

I've analyzed this issue and here's my proposed implementation plan:

Root Cause: When openClineInNewTab() is called from command handlers (popoutButtonClicked at line 105 or openInNewTab at line 107 in src/activate/registerCommands.ts), the returned ClineProvider is discarded without calling API.registerListeners() on it. In contrast, when called from API.startNewTask() (line 185-186 in src/extension/api.ts), registerListeners() is properly called.

Proposed Fix:

1. Add a module-level callback hook in src/activate/registerCommands.ts:

   • Export a setOnTabProviderCreated(callback) function that stores a callback
   • Call this callback inside openClineInNewTab() after the tab provider is created (before returning it)

2. In src/extension/api.ts, during API construction:

   • Import and call setOnTabProviderCreated() with a callback that invokes this.registerListeners(provider)
   • This ensures every tab provider created via commands gets event listeners registered

3. Add tests to verify that the callback is invoked when openClineInNewTab is called, and that events from tab providers are forwarded through the API.

This approach is minimally invasive -- it adds a simple hook without changing the existing function signature of openClineInNewTab or requiring the API instance to be passed into command registration.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[nhjelle]

@roomote I approve

[roomote]

Thanks for the approval! I've seen your comment and will proceed with the implementation. I'll open a PR to share progress shortly.

[roomote]

Opened a draft PR with my attempt at addressing this: #11510. Feedback welcome!