Diagnosed breaking API change in bun executable

Summary

Closed, Completed

Reproduce
Tested bun executable on macOS and Linux.
Reproduce
Understand
Identified breaking change in Editor constructor API.
Understand
Understand
Reviewed changelog for documentation of change.
Understand
Edit
Explained fix to update extension to new API.
Edit

looks like the latest pi release, self-contain3ed bun executable is broken. download from gh, test on macos (this machine) and linux (use docker)

macOS version works for --version. Let me test actual usage:

macOS arm64 works fine. Now testing Linux x64 in Docker:

Rosetta issue with x64 on arm64 Mac. Let me download the Linux arm64 version and test:

Expected (no API key). Let me pass one:

Linux arm64 works. Let me also test Linux x64 with the correct platform:

All tests pass. The v0.48.0 self-contained executables are working correctly:

Platform	Version Check	Actual Usage
macOS arm64 (native)	✅	✅
Linux arm64 (Docker)	✅	✅
Linux x64 (Docker)	✅	✅

The release appears to be functional. What issue were you experiencing? Can you provide more details about what's broken?

/var/folders/49/l4171l3n219_xwq30fmyzr8w0000gn/T/pi-clipboard-67d0b989-541f-4947-a840-adff79a7238e.png

Now I see the issue. The error is:

TypeError: undefined is not an object (evaluating 'this.tui.terminal.rows')  at render (/$bunfs/root/pi:193291:43)  at <anonymous> (/home/zenobius/.pi/agent/extensions/powerline-footer/index.ts:269:39)

TypeError: undefined is not an object (evaluating 'this.tui.terminal.rows')  at render (/$bunfs/root/pi:193291:43)  at <anonymous> (/home/zenobius/.pi/agent/extensions/powerline-footer/index.ts:269:39)

This is happening when a user has a custom extension (powerline-footer) that's trying to access this.tui.terminal.rows, but this.tui.terminal is undefined.

The issue is likely in the TUI terminal initialization or in how extensions access the terminal. The extension is at /home/zenobius/.pi/agent/extensions/powerline-footer/index.ts:269:39.

Let me check what the current code looks like in the coding-agent TUI to see how terminal is initialized and when it might be undefined.

The error is:

This is happening in a user's custom extension (powerline-footer) at line 269. The extension is trying to access this.tui.terminal.rows but this.tui.terminal is undefined.

Let me check how the terminal is exposed in the TUI:

I see. On line 948, the factory is called with this.ui which is a Tui instance. So when the powerline-footer extension creates a component like:

The tui passed is this.ui. Let me check where this.ui is assigned in interactive-mode.ts:

I see that this.terminal is assigned in the constructor of TUI. So tui.terminal should always be defined after construction.Looking back at the error:TypeError: undefined is not an object (evaluating 'this.tui.terminal.rows')at render (/$bunfs/root/pi:193291:43)at <anonymous> (/home/zenobius/.pi/agent/extensions/powerline-footer/index.ts:269:39)

It says this.tui.terminal is undefined, not this.terminal. This means the user's extension has a component with this.tui set to something, but this.tui.terminal is undefined.Wait, actually I think the error is on line 193291 in the bundled pi file (at render), but triggered from the extension at line 269.

Let me check if this could be a render-time issue where tui might get disposed or something changes. Let me look at how extensions store tui reference and what happens during render.

Actually, looking more carefully at the error - the issue might be in the extension storing a reference to this.tui and later that reference becomes stale. Let me think about what could cause this.tui.terminal to become undefined...

Actually wait, TUI.terminal is a public property that's assigned once in the constructor and never reassigned. Unless... something is disposed or the tui instance itself is recreated.

Let me look at what happens when sessions switch or if there's any cleanup that might affect this.

The terminal is only assigned once. Let me check if there's any case where the tui instance could be recreated or if there's any weird race condition.Let me look at the actual line numbers in the bundled file. The error points to line 193291 and also mentions components like editor.ts. Let me check how the error might be occurring.Actually, looking back at the screenshot, I see:- Line 193286-193291 show maxPadding/paddingX/contentWidth calculations and then this.tui.terminal.rows- The error comes from render method Let me look for render methods that access this.tui.terminal.rows:

I see the issue. On line 399:tsconst terminalRows = this.tui.terminal.rows;

This accesses this.tui.terminal.rows. If this.tui is undefined or this.tui.terminal is undefined, this will throw.Now let me understand when this could be undefined. Looking at the constructor:tsconstructor(tui: TUI, theme: EditorTheme, options: EditorOptions = {}) { this.tui = tui; ...}

The tui is assigned to this.tui directly. For this.tui.terminal to be undefined, either:1. tui was passed as undefined or something with no terminal2. tui.terminal was later set to undefined

Looking at TUI class, terminal is set in the constructor and never reassigned. So it should always be valid.

Wait, let me re-read the error more carefully from the screenshot. The error occurs twice with the same stack trace, which suggests the extension's render method is being called multiple times.

The error trace shows:TypeError: undefined is not an object (evaluating 'this.tui.terminal.rows') at render (/$bunfs/root/pi:193291:43) at <anonymous> (/home/zenobius/.pi/agent/extensions/powerline-footer/index.ts:269:39)

The powerline-footer/index.ts:269:39 is where the render is being triggered from. The actual error is in the bundled pi code at line 193291, which corresponds to editor.ts line 399.This is strange because a powerline-footer extension shouldn't be rendering via editor.ts...

Unless the powerline-footer extension creates its own Editor component and the tui passed to it somehow doesn't have a terminal.Let me check if there's anything specific about how custom footers work and whether tui could be problematic.Actually, looking at the interactive-mode.ts:tsthis.customFooter = factory(this.ui, theme, this.footerDataProvider);

The this.ui passed should be valid since it's the TUI instance. But the powerline-footer extension might be creating an internal Editor with a tui that wasn't properly initialized. I need to trace how the extension receives and uses the tui parameter to see if there's a path where it could be null or missing the terminal property.

This commit changed the Editor constructor signature! The old signature was:tsnew Editor(theme)The new signature is:tsnew Editor(tui, theme)

This is a breaking change! The user's powerline-footer extension was probably written for the old API where the first parameter was theme. Now with the new API, if their code did:tsconst editor = new Editor(theme, options);Instead of:tsconst editor = new Editor(tui, theme, options);

Then this.tui would be assigned the theme object, not a TUI instance, so this.tui.terminal would be undefined.

Let me verify this by checking the old API signature:

Confirmed! The old constructor was:tsconstructor(theme: EditorTheme)The new constructor is:tsconstructor(tui: TUI, theme: EditorTheme, options: EditorOptions = {})This is a breaking change. If the user's extension created an Editor with the old API:tsconst editor = new Editor(theme);Now with the new API, this assigns theme to this.tui, so when the code accesses this.tui.terminal.rows, it's actually accessing theme.terminal.rows which is undefined.The fix would be for the user to update their extension to the new API:tsconst editor = new Editor(tui, theme);

But this is a breaking change that should have been documented in the changelog. Let me check if it was properly documented:

Found it! Commit 356a4825 changed the Editor constructor signature:

Old API: new Editor(theme)
New API: new Editor(tui, theme, options?)

This is a breaking change. If the user's powerline-footer extension uses the old signature:

Now theme gets assigned to this.tui, so this.tui.terminal is undefined (since theme has no terminal property).

Let me check the changelog to see if this was documented:

The changelog in v0.47.0 does document this breaking change:> Editor constructor now requires TUI as first parameter: new Editor(tui, theme). This enables automatic vertical scrolling when content exceeds terminal height.So it IS documented, but it's a breaking change that could affect extensions. The user's extension was written for the old API.The issue is:1. v0.47.0 introduced this breaking change (January 16, 2026)2. v0.48.0 was released the same day 3. The user's powerline-footer extension hasn't been updated for the new API

The binary itself is NOT broken - it's working as designed. The user's extension needs to be updated to use the new Editor API.

Let me verify by checking the example extensions to see if they were updated:

The binary is not broken. The issue is a breaking API change in v0.47.0.

Summary:

Commit 356a4825 changed Editor constructor from new Editor(theme) to new Editor(tui, theme)
This was documented in the v0.47.0 changelog as a breaking change
The user's powerline-footer extension is using the old API
When the extension does new Editor(theme), the theme object gets assigned to this.tui, so this.tui.terminal is undefined

The fix is for the user to update their extension:

// Old (broken):const editor = new Editor(theme);
// New (correct):const editor = new Editor(tui, theme);

// Old (broken):const editor = new Editor(theme);
// New (correct):const editor = new Editor(tui, theme);

However, we could improve the error message by adding validation in the Editor constructor. Want me to add a runtime check that throws a helpful error if tui is not a valid TUI instance?