Fixed UI notification issue on extension reload

Summary

Closed, Completed

Understand
Investigated extension command registration and UI notification.
Understand
Build
Bound UI contexts on startup for reload support.
Build
Edit
Updated changelog with the fix.
Edit
Verify
Ran tests and pushed fix to main branch.
Verify

i had you write a trivial extension in another session to .pi/extensions/test.ts (no longer there). it registered a command /test that would use ui.notify().

when i started the session, test.ts didn'T exist yet, you created it. then i did /reload. the /test command got registered, but running it did not show the ui notification. can you figure out why that is?

The user is describing an issue with a pi extension. They created a test extension that registered a /test command using ui.notify(), but when they ran the command after /reload, the notification didn't show.

Let me investigate how extensions work in pi, particularly around UI notifications and command registration. I should look at:

The extension documentation
How ui.notify() works
How commands are registered and executed

Let me start by reading the extension docs and related code.

Let me investigate how extensions and UI notifications work in pi.

Readextensions.md

Readextensions

Readnotify.ts

Readhello.ts

Let me look at how commands work and how ctx.ui.notify is implemented:

Readrunner.ts

Readloader.ts

Now I understand the loading process. Let me look at how the interactive mode sets up the UI context and when commands are run. The key issue is:

Extensions are loaded and commands are registered during extension loading
The setUIContext is called later by the mode (interactive mode) to provide the actual UI implementation
When a command is registered, it captures ctx.ui - but at registration time, this might be the noOpUIContext

Let me look at how commands are executed to see if there's a closure issue.

I see that createContext() is called at command execution time and it uses this.uiContext. The issue is:

typescript

createContext(): ExtensionContext {    const getModel = this.getModel;    return {        ui: this.uiContext,  // <-- This captures the value at call time        ...    };}

createContext(): ExtensionContext {    const getModel = this.getModel;    return {        ui: this.uiContext,  // <-- This captures the value at call time        ...    };}

The context captures this.uiContext at the time createContext() is called. So when the command runs, it gets the current UI context.

Let me check when setUIContext is called in the interactive mode. The issue could be:

/reload loads extensions but doesn't re-set the UI context
The command is getting the wrong UI context

Let me look at the /reload implementation:

I see the flow now. Let me trace it:

Interactive mode calls session.bindExtensions({ uiContext: ... }) which stores the UI context in _extensionUIContext and applies it to the runner
On /reload, session.reload() is called which:
- Calls _buildRuntime() which creates a NEW ExtensionRunner
- Calls _applyExtensionBindings(runner) which sets runner.setUIContext(this._extensionUIContext)

So the flow seems correct. Let me look more closely at the interactive mode's handleReloadCommand to see if maybe the issue is with how the UI context is created.

Actually, wait. Let me look at what _extensionUIContext contains. This is set by bindExtensions({ uiContext: ... }). Let me see what the interactive mode passes:

I see. showStatus adds a Text component to the chatContainer. This seems fine. Let me trace through the code once more.

When a command is executed:

_extensionRunner.getCommand(commandName) gets the command
_extensionRunner.createCommandContext() creates the context with this.uiContext (current UI context)
command.handler(args, ctx) is called

So when /reload is executed:

handleReloadCommand() is called which calls this.session.reload()
reload() creates a NEW ExtensionRunner via _buildRuntime()
_buildRuntime() then calls _applyExtensionBindings(runner) which calls runner.setUIContext(this._extensionUIContext)

So the UI context IS set on the new runner. But wait, let me check the noOpUIContext usage again:

typescript

const noOpUIContext: ExtensionUIContext = {	select: async () => undefined,	confirm: async () => false,	input: async () => undefined,	notify: () => {},  // <-- This is a no-op!	...};

const noOpUIContext: ExtensionUIContext = {	select: async () => undefined,	confirm: async () => false,	input: async () => undefined,	notify: () => {},  // <-- This is a no-op!	...};

And in ExtensionRunner:

Then setUIContext is called to set the real UI context. This seems fine.

Let me check if maybe the issue is with how runner.setUIContext(this._extensionUIContext) works when _extensionUIContext is undefined:

I see it now!

typescript

setUIContext(uiContext?: ExtensionUIContext): void {    this.uiContext = uiContext ?? noOpUIContext;}

setUIContext(uiContext?: ExtensionUIContext): void {    this.uiContext = uiContext ?? noOpUIContext;}

If uiContext is undefined, it falls back to noOpUIContext. And in _applyExtensionBindings:

typescript

private _applyExtensionBindings(runner: ExtensionRunner): void {    runner.setUIContext(this._extensionUIContext);  // Could be undefined!    ...}

private _applyExtensionBindings(runner: ExtensionRunner): void {    runner.setUIContext(this._extensionUIContext);  // Could be undefined!    ...}

The _extensionUIContext is only set when bindExtensions() is called. Let me check what happens on startup vs reload. The issue might be that _extensionUIContext is not set properly.

Actually wait, let me re-read bindExtensions:

typescript

async bindExtensions(bindings: ExtensionBindings): Promise<void> {    if (bindings.uiContext !== undefined) {        this._extensionUIContext = bindings.uiContext;    }    ...}

async bindExtensions(bindings: ExtensionBindings): Promise<void> {    if (bindings.uiContext !== undefined) {        this._extensionUIContext = bindings.uiContext;    }    ...}

So _extensionUIContext is set once by interactive mode during initialization. And when /reload happens, _applyExtensionBindings passes the stored _extensionUIContext to the new runner. This should work.

Let me check if maybe there's an issue with the interactive mode's createExtensionUIContext:

I notice something interesting. The createExtensionUIContext() creates a NEW object each time it's called. In the setupExtensionShortcuts function, for shortcuts, it creates a fresh context with this.createExtensionUIContext(). But for the bindExtensions call, it only happens once during initialization.

Let me trace through what happens when:1. pi starts2. user creates test.ts extension 3. user does /reload 4. the extension is loaded 5. user runs /testAt step 4, the extension is loaded via _buildRuntime(). The _applyExtensionBindings() is called which sets the UI context on the runner.At step 5, when the /test command runs:

_extensionRunner.getCommand("test") returns the command
_extensionRunner.createCommandContext() creates the context with this.uiContext- The handler is called with the context

The createCommandContext() returns { ...this.createContext(), ... } which has ui: this.uiContext. And this.uiContext is set to the value from setUIContext().

Hmm, this should work. Let me check if maybe the issue is that the extension was created before /reload was called, and the extension stores a reference to the UI context somewhere.

Actually, wait! Looking back at the user's description: "test.ts didn't exist yet, you created it. then i did /reload." So:1. Pi started (no test.ts extension) 2. I (the agent) created test.ts 3. User did /reload 4. Extension was loaded 5. User ran /test

Let me verify this by looking at what happens during extension loading. The createExtensionAPI function creates the API that the extension uses. When the extension calls pi.registerCommand(), it stores the command. But the command's handler is a function that the extension provides, and it takes ctx as a parameter.Let me look again:

Readtypes.ts200 lines

Let me check the exact flow by looking at how the command gets executed after reload:

I see the flow:1. _tryExecuteExtensionCommand is called2. It gets the command from this._extensionRunner.getCommand(commandName)3. It creates context via this._extensionRunner.createCommandContext()4. The context includes ui: this.uiContext from the runnerSo when /reload happens:1. A new ExtensionRunner is created in _buildRuntime2. _applyExtensionBindings is called which sets runner.setUIContext(this._extensionUIContext)3. Commands are now available on the new runner4. When /test runs, the context is created with the runner's uiContext

This should work. Let me check if _extensionUIContext itself might be the problem. Maybe it's getting garbage collected or something? Or maybe there's a race condition.

Wait, I need to check something. Let me look at how the command execution flows from the interactive mode:

I see the flow now:1. prompt() is called with /test 2. _tryExecuteExtensionCommand() is called which:

Gets the command from the extension runner
Creates a context via createCommandContext()
Calls command.handler(args, ctx)

Let me add some debug logging to understand what's happening. Actually, wait, I think I found the issue!

Let me look at createContext() again:

typescript

createContext(): ExtensionContext {    const getModel = this.getModel;    return {        ui: this.uiContext,  // <-- Captures the value at call time        hasUI: this.hasUI(),  // <-- Also called at call time        ...    };}

createContext(): ExtensionContext {    const getModel = this.getModel;    return {        ui: this.uiContext,  // <-- Captures the value at call time        hasUI: this.hasUI(),  // <-- Also called at call time        ...    };}

If the issue is that hasUI() returns false, then... wait, that shouldn't affect ctx.ui.notify() working. Let me check what showExtensionNotify does again:

Readinteractive-mode.ts30 lines

I see that showStatus adds a Text component to the chat container and calls this.ui.requestRender(). This should work.Let me think about this differently. The user says "the /test command got registered, but running it did not show the ui notification." This means the command is found (registered correctly), but ctx.ui.notify() didn't show anything.If I look at the flow:1. /test is entered2. Interactive mode sends it to session.prompt("/test") 3. _tryExecuteExtensionCommand is called4. The command is found (yes, because the user said it got registered)5. createCommandContext() is called which includes ui: this.uiContext 6. The command handler is called with this context7. The handler calls ctx.ui.notify(...)If this.uiContext is the no-op context, then notify would be a no-op. Let me check the noOpUIContext.notify:

typescript

const noOpUIContext: ExtensionUIContext = {    ...    notify: () => {},  // <-- This is a no-op!    ...};

const noOpUIContext: ExtensionUIContext = {    ...    notify: () => {},  // <-- This is a no-op!    ...};

Yes! If the no-op context is being used, notify() does nothing.

So the question is: why is this.uiContext still the noOpUIContext after /reload?

Let me trace through /reload:1. handleReloadCommand() is called 2. It calls this.session.reload()3. reload() calls _buildRuntime() which creates a NEW ExtensionRunner4. _buildRuntime calls _applyExtensionBindings(runner)5. _applyExtensionBindings calls runner.setUIContext(this._extensionUIContext)

The key is: is this._extensionUIContext set?It should have been set during initialization in bindExtensions().

I need to check whether bindExtensions actually runs during startup and properly initializes this._extensionUIContext with the real UI context instead of leaving it as the no-op version.

Readinteractive-mode.ts50 lines

initExtensions() is called during the run() method (initialization). But the key point is that bindExtensions is only called if extensionRunner exists.

Now let me understand the issue: when pi starts initially and no test.ts exists, initExtensions() is called. At that point, this.session.extensionRunner might be undefined (no extensions loaded yet). So bindExtensions is NOT called and _extensionUIContext remains undefined.Then when /reload happens:1. test.ts now exists 2. session.reload() creates a NEW ExtensionRunner (with the test.ts extension) 3. _applyExtensionBindings(runner) is called4. It calls runner.setUIContext(this._extensionUIContext)5. But _extensionUIContext is still undefined!6. So setUIContext(undefined) sets this.uiContext = noOpUIContextThat's the bug! When /reload happens, the UI context is not re-created if it wasn't created initially.Let me verify my understanding by looking at the reload handler to see if it re-initializes the UI context:

Readinteractive-mode.ts60 lines

Readinteractive-mode.ts45 lines

actually, codex, please take over

Acknowledging takeover and summarizing analysis

Ok, I'll take over. The UI context issue likely happens because if no extensions exist at startup, the initialization skips binding the UI context after reload. Should I reproduce the issue, inspect files further, or proceed with a fix?

Explaining UI context reload issue and proposing fix options

After reload, the extension loads but _extensionUIContext is undefined, so the runner uses a no-op UI context, causing notifications not to appear during tests. To fix this, reload could call bindExtensions or create the UI context anew—possibly in the reload handler or session code. Should I implement this fix? If so, where do you want it applied?

Taking over. The likely cause is that when pi started there were no extensions, so InteractiveMode.initExtensions() returned early and never called session.bindExtensions(). That means _extensionUIContext stayed undefined. On /reload, AgentSession.reload() creates a new ExtensionRunner and calls _applyExtensionBindings, which passes the undefined UI context. ExtensionRunner.setUIContext(undefined) falls back to the no-op UI context, so ctx.ui.notify() does nothing. That matches what you saw.

If you want, I can prepare a fix. One option is to re-run initExtensions() after session.reload() or call session.bindExtensions() inside handleReloadCommand() whenever a new runner exists.

ohhhh that explains it! i was running it in ../shittycodingagent.ai/ and i think i have no user extensions loaded? yeah, i don't. howe can we fix that?

Explaining extension UI context reload fix

The fix involves ensuring the UI context binds in interactive mode even if no extensions start initially. This means calling session.bindExtensions at startup without exiting early when no extensionRunner exists, so _extensionUIContext is set for later reloads. I can implement this if requested.

Recommending reload UI context fix

The best approach is to call session.bindExtensions after reload in handleReloadCommand to ensure the UI context updates when a new runner appears. Since initExtensions exits early without a runner, bindExtensions offers a safer way to rebind without redundant setup calls. I can implement this if wanted and explain options for handling no extensions at startup.

It happens when you start with zero extensions. initExtensions() returns early, so session.bindExtensions() never runs and _extensionUIContext stays undefined. On /reload, the new runner gets noOpUIContext, so ctx.ui.notify() does nothing.

Fix options:

In InteractiveMode.initExtensions(), call session.bindExtensions() even when there is no runner, so the UI context is stored for future reloads.
In handleReloadCommand(), after session.reload(), call session.bindExtensions() with createExtensionUIContext() if a runner exists.
Call initExtensions() after reload instead of only rebuilding shortcuts.

Tell me which approach you want, or I can pick one and implement it.

i suppose we need to do the same in prc and print(json mode?

also, i would think agent-session.ts reload() would handle the rewiring of extensions and contexts. it's very weird for modes to having to do that on reload. what concise solution would make it so agent-session.ts handles all of that?

also because if we registered the ui context after session.reload(), extensions might already have been run, specifically session_start events could have been emitted, wherein extensions can do ui things, no?

Analyzing extension binding persistence

The issue is that extension bindings aren’t consistently stored or reapplied across agent-session reloads because bindExtensions isn’t always called when no extensionRunner exists initially. To fix this, either the mode should always call bindExtensions to store bindings regardless of runner presence, or agent-session should manage storing and reapplying bindings independently before emitting session_start on reload.

Confirming mode behavior on extension bindings

The core problem is that modes like interactive skip calling bindExtensions if no extensionRunner, leaving UI context unset. To fix, modes (including rpc and print) should always call bindExtensions to set UI context regardless of runner presence, ensuring session reloads can reapply bindings. Next, I'll review rpc-mode and print-mode to verify if they also skip binding when no extensions.

Readrpc-mode.ts80 lines

Readprint-mode.ts120 lines

Proposing session-level extension binding

Considering moving extension binding from modes to AgentSession to ensure context is set regardless of runner presence, either by calling bindExtensions unconditionally at startup or managing default bindings inside AgentSession for consistent context during reloads.

Clarifying extension binding fix

To ensure UI context is set before reload, all modes should call session.bindExtensions unconditionally at startup—even if no extension runner exists—so AgentSession stores bindings early. On reload, AgentSession already reapplies stored bindings before emitting session_start, preserving correct context without modes handling rewiring. This applies to interactive, RPC, and print modes.

Yes, same issue in RPC and print or json. They only call session.bindExtensions() when session.extensionRunner exists, so if you start with zero extensions the UI context never gets stored. On /reload, the new runner gets noOpUIContext, so ctx.ui.notify() does nothing.

AgentSession.reload() already rebinds and emits session_start if bindings are present. The missing piece is that the bindings never get stored when there were no extensions on startup. The concise fix is to call session.bindExtensions() unconditionally in each mode during initialization, even when there is no extension runner. That stores the UI context and command actions up front. Then reload reuses them and session_start runs with the real UI context.

This also answers your last point. If we only bind after reload(), session_start can fire before the UI is set. So the binding must be stored before reload runs.

If you want me to implement it, I will update:

packages/coding-agent/src/modes/interactive/interactive-mode.ts
packages/coding-agent/src/modes/rpc/rpc-mode.ts
packages/coding-agent/src/modes/print-mode.ts

Tell me to proceed.

please implement concisely

Clarifying file reading approach

The instructions require reading full files before editing without using offsets or limits, but the read tool truncates large files; this conflicts with the mandate. The next step is to resolve how to handle large files given this constraint.

Resolving reading large files strategy

I clarified that reading a file "in full" means initially calling read without offset/limit even if truncated, then following up with offset reads to complete it; this respects instructions while ensuring full content. The plan is to start with smaller files for edits, then handle the large interactive-mode.ts similarly.

Readrpc-mode.ts

Refactoring extension binding to always call

Planning to call session.bindExtensions unconditionally in both RPC and interactive modes, removing extensionRunner presence checks; this ensures UI context is always created and bound, while handling runner-dependent features like shortcuts and resource display conditionally.

Finalizing extension binding uniformity and reading large file

Decided to always create UI context and call bindExtensions unconditionally across modes, adjusting handling based on runner presence; preparing to read the full interactive-mode.ts despite its size to ensure safe comprehensive edits.

Readinteractive-mode.ts

Readprint-mode.ts

Refactoring extension initialization

Planning to always call bindExtensions by moving UI context creation and bindExtensions call before checking for the extension runner, then conditionally run setupShortcuts and show resources afterward for clearer flow and to ensure UI context setup even without a runner.

Preparing precise code replacements

I'm crafting exact old and new code blocks for initExtensions and updating rpc-mode and print-mode to always call bindExtensions without checking extensionRunner first, ensuring no extra blanks for exact text match using the edit tool.

Editedinteractive-mode.ts

Editedrpc-mode.ts

Readrpc-mode.ts40 lines

Readrpc-mode.ts20 lines

Editedrpc-mode.ts

Editedprint-mode.ts

Confirming extension binding ensures UI context on reload

The bindExtensions call now always runs, setting UI context upfront even if no extension runner existed before reload, ensuring session_start emits with proper context. Next, I'll verify interactive mode calls bindExtensions unconditionally to avoid race conditions.

Validating unconditional binding won't break logic

Calling bindExtensions always is safe since it stores handlers and only emits session_start if extensionRunner exists, preserving prior behavior even in print mode without UI context. Next, I'll run the required full npm run check to catch any errors or warnings after these code changes.

Summarizing extension binding changes

Extensions now bind in all modes irrespective of the extension runner, ensuring UI context persists across reloads with session info saved. The initialization was adjusted to bind extensions before checking the runner, and RPC and print modes also bind unconditionally. Tests ran successfully with npm run check. Key files updated include those managing interactive, RPC, and print modes.

Summary:

Updated packages/coding-agent/src/modes/interactive/interactive-mode.ts to bind extension UI context before checking for a runner, so reload has the context even when starting with zero extensions.
Updated packages/coding-agent/src/modes/rpc/rpc-mode.ts and packages/coding-agent/src/modes/print-mode.ts to bind extensions unconditionally for the same reason.

Tests:

npm run check

lgtm, commit and push, add a changelog entry

ReadCHANGELOG.md

EditedCHANGELOG.md