v1.0.26

The prompt band, one row like Claude Code's

This release makes your messages in the claude-code preset look like Claude Code's: the band covers only the text. It also fixes the spacing under the welcome card that this change would otherwise have broken.

Changed

• Your messages' band covers only their text. This applies with messages.assistantMarker on (the claude-code preset).
  • Cause: measured on screenshots of both, the ❯ already sat where Claude Code puts it, about 6 px inside the band's first cell. The cramped look came from the band's shape. Pi's band had a full blank row above and below the text but nothing to the left of the marker. Claude Code's band is just the text rows.
  • Pi's blank band rows above and below your text are gone. A blank row between paragraphs stays inside the band.
  • Pi's own spacing still leaves one blank row above and below each message.
  • The ❯, the band's left edge, and the text columns stay where 1.0.25 put them.

Fixed

• Your first message would have sat on the welcome card's bottom edge.
  • Pi normally puts blank rows around its own startup header. A quiet startup (quietStartup: true) leaves them out, and Pi adds no blank row before the first message in an empty chat.
  • Since 1.0.23 dropped the card's bottom padding, the band's blank top row was all that separated the card from your first message, whether new or restored on resume.
  • When the card is Pi's header, it now keeps one blank row below it.

Side effects

• Verbose startup (quietStartup: false or --verbose): Pi adds its own blank row as well. That leaves two blank rows between the card and Pi's resource list, as above the card. An extension can't tell which kind of startup ran.
• Pi 0.85 at startup: two blank rows between the card and the editor instead of one. Pi 1.1 keeps the editor at the bottom of the screen, so nothing visible changes there.
• default preset: your first message's band starts one row lower.
• startup.mode: "off": with no card, your first message is the first row on screen. Its text row now sits at the top, where Pi's painted blank band row used to be.
• Card as a widget: when the card sits above the editor as a widget, it is unchanged.

Verification

• CI: this repository has no configured GitHub Actions workflows, check-runs, or commit-status contexts for the release commit. The local release gates below all passed.
• npm ci and npm run check: typecheck, 435 unit/integration/golden tests, dependency boundaries, production build, and package smoke.
  • New tests check four things:
    • the band drops Pi's blank rows above and below the text;
    • a blank row between paragraphs stays painted;
    • the card mounted as Pi's header ends with a blank row;
    • the card as a widget, or a card with no rows, adds none.
  • Mutation checks:
    • Restoring the old row handling fails exactly the three band tests.
    • Removing the header row, or adding it to the widget too, fails the header test.
  • Each of the two change commits passes npm run check on its own.
• npm run test:e2e:readonly-tools: 25/25 packed-package CLI/RPC cases on Pi 0.99.1 with pi-hashline-edit-pro 4.5.1.
• npm publish --dry-run: the expected 7-file npm artifact.
• Real TUI on Pi 1.1.0 (bundled build), set up like the reporter's:
  • Setup: Titanium theme, quietStartup: true, an isolated agent directory, the project outside the home directory, and no fd/rg or trust notices in the chat.
  • The prompts were a link-first message that wraps, then a short follow-up. Cell backgrounds were read back from the terminal buffer.
  • claude-code:
    • The card's bottom edge is on row 17 and row 18 is unpainted.
    • The band covers only rows 19–20 (the two text rows), from column 1 to 98 of 100. The ❯ is in column 1 and the text and its wrapped row start in column 3.
    • The follow-up's band is its one text row. The rows above and below it are plain.
    • Compared with 1.0.25 in the same setup, exactly the two blank band rows per message are gone. Nothing else moved.
  • default: one blank row under the card, then Pi's own padded band from column 0 to 99 with no marker, as before.
  • Other cases:
    • Pi 0.85.0 renders the same rows and cells as Pi 1.1.
    • A resumed session (-c) puts the restored first message one blank row under the card.
    • A 64-column terminal puts it one blank row under the compact logo.
    • A verbose startup shows two blank rows between the card and the resource list.

Tested on Windows x64 with Node 24.11.1. Linux/macOS runs were not part of this verification.

Install / update

Published on npm. Verified:

• the registry latest tag, gitHead (the release commit), and tarball shasum;
• a clean install whose files match the release build byte for byte;
• the same real-TUI runs on the installed package. On Pi 1.1 (claude-code, default, verbose startup, 64 columns) and Pi 0.85, the transcript matches the pre-release build row for row, apart from run timings and the test directory's name.

pi install npm:@nguyenquangthai/pi-omp-theme@1.0.26
# For an existing unpinned installation:
pi update npm:@nguyenquangthai/pi-omp-theme

v1.0.25

The prompt marker, fixed at the root

This release fixes two problems with the 1.0.24 prompt marker in the claude-code preset.

Fixed

• A message that opened with a link had its ❯ on the second row.
  • Cause: the theme's text check in the messages module read an OSC escape sequence as running to the next BEL. Pi closes its OSC 8 hyperlinks with ST (ESC \), so a link swallowed the rest of its row, the row read as blank, and the marker went to the next row.
  • The same misread kept the messages.assistantPrefix gutter off an answer that opens with a link. This predates 1.0.24; the new marker made it visible.
  • OSC sequences now end at BEL or ST. Other parts of the theme already read them that way.
• The prompt's band didn't line up with the answers' ●. In 1.0.24 Pi's band still ran edge to edge, with the ❯ one column inside it. Claude Code's band starts in the marker column, and now this one does too:
  • The band starts under the answers' ● and stops one column short of the right edge.
  • The ❯ fills the band's first cell, and the text starts in the same column as the answers' text.

Kept

• Pi's blank band rows above and below the text are kept. This is the one visible difference from Claude Code, whose band covers only the text rows.
• Without the assistant marker, your messages are untouched.

How it stays contained

• If any band row lacks Pi's shape (background escape, padding, text), the whole message keeps Pi's own rendering. A partly marked block would mix widths, so the theme never draws one.

Verification

• CI: this repository has no configured GitHub Actions workflows, check-runs, or commit-status contexts for the release commit. The local release gates below all passed.
• npm ci and npm run check: typecheck, 433 unit/integration/golden tests, dependency boundaries, production build, and package smoke.
  • New regression tests feed the exact link row Pi 1.1 writes (OSC 8 closed with ST) to the prompt marker and to the assistantPrefix gutter.
  • With the ST handling removed, exactly those two tests fail.
  • The layout tests check that every band row is painted from column 1 to one column short of the right edge, with the edge columns left plain.
  • The fix commit passes npm run check on its own.
• npm run test:e2e:readonly-tools: 25/25 packed-package CLI/RPC cases on Pi 0.99.1 with pi-hashline-edit-pro 4.5.1.
• npm publish --dry-run: the expected 7-file npm artifact (152.0 kB packed).
• Real TUI on Pi 1.1.0 (bundled build), with the Titanium theme and an isolated agent directory. The prompt typed was https://github.com/… tôi đang cần…. Cell backgrounds were read back from the terminal buffer:
  • claude-code: every band row is painted from column 1 to column 98 of 100, and columns 0 and 99 are plain. The ❯ sits at column 1 on the link row, with the answers' ● also at column 1. The text and its wrapped row start at column 3, like the answers' text.
  • default: the band runs from column 0 to 99 with no marker, as before.

Tested on Windows x64 with Node 24.11.1. Linux/macOS runs were not part of this verification.

Install / update

Published on npm. Verified:

• the registry latest tag, gitHead (the release commit), and tarball shasum;
• a clean install whose files match the release build byte for byte;
• a real Pi 1.1.0 run of the installed package with the same link-first prompt. In the claude-code and default presets, it renders exactly as the pre-release build did, apart from run timings.

pi install npm:@nguyenquangthai/pi-omp-theme@1.0.25
# For an existing unpinned installation:
pi update npm:@nguyenquangthai/pi-omp-theme

v1.0.24

Your messages line up with the answers

In the claude-code preset, your messages now start with the prompt's ❯, and their text lines up with the answers below them, as in Claude Code. The welcome card's !! tip now says what it does.

Fixed

• Inline chrome: your messages didn't line up with the answers. With messages.assistantMarker on (the claude-code preset), an answer starts with ● on Pi's gutter and its text begins two columns later. Pi draws your message itself, with the text on the gutter, so your text started two columns left of the answer's. Pi without the theme has both at the same column; the shift came from the theme's marker.
  • Your messages now start with the prompt's ❯ in the marker column. Their text, wrapped lines included, starts in the same column as the answer's.
  • Pi's band, colors, and prompt zone (OSC 133) are kept. The glyph is the editor's prompt glyph: ❯, > in ASCII mode, or your theme.glyphs.prompt.
  • Without the assistant marker, your messages are untouched.

Changed

• The !! tip. The welcome card read !! bash, no context, taken from Pi's startup hint. That could be read as a note about context files such as AGENTS.md, and it is fixed text that never looked at them. !!command runs a command and shows its output without sending it to the model; !command includes the output in the conversation. The tip now reads bash, not sent to model, the way Pi's usage guide puts it. The gallery images show the new wording.

How it stays contained

• The theme decorates Pi's UserMessageComponent.rebuild only when it recognizes the native method, the same check every other decorated surface goes through. It recognizes Pi 0.85 (a band Box around the Markdown), Pi 1.1 (a Markdown that paints its own band), and Pi's bundled build. Anything else keeps Pi's own rendering.
• It installs only when the assistant marker is on.
• Pi's lines are rendered two columns narrower and widened again right after their left padding. The inserted cells sit inside the band's background, so every row keeps its full width.

Verification

• CI: this repository has no configured GitHub Actions workflows, check-runs, or commit-status contexts for the release commit. The local release gates below all passed.
• npm ci and npm run check: typecheck, 431 unit/integration/golden tests, dependency boundaries, production build, and package smoke.
  • 5 tests are new for the prompt marker. They use Pi 0.85's real component and Pi 1.1's shape rebuilt from pi-tui's Markdown, and they check:
    • the same text column as an answer;
    • hanging wrapped rows;
    • the full-width band and the OSC 133 zone;
    • outputPad 0;
    • Pi's output untouched without markers;
    • installation only alongside the assistant marker.
  • One assertion pins the new !! wording.
  • Each intermediate commit passes npm run check on its own.
• npm run test:e2e:readonly-tools: 25/25 packed-package CLI/RPC cases on Pi 0.99.1 with pi-hashline-edit-pro 4.5.1.
• npm publish --dry-run: the expected 7-file npm artifact (151.6 kB packed).
• Real TUI on Pi 1.1.0 (bundled build), with the Titanium theme and an isolated agent directory. Columns and colors were read back from the terminal buffer.
  • claude-code: the prompt's ❯ sits at column 1, and its text and wrapped row start at column 3, the same column as ● Check the file first.. The band's background runs through the marker cells.
  • default: no marker, and your text and the answer's both start at column 1, as before.
  • The tips row reads !! bash, not sent to model.

Tested on Windows x64 with Node 24.11.1. Linux/macOS runs were not part of this verification.

Install / update

Published on npm. Verified:

• the registry latest tag, gitHead (the release commit), tarball shasum, and the pi.image gallery URL;
• a clean install whose files match the release build byte for byte;
• a real Pi 1.1.0 run of the installed package. In the claude-code and default presets, the transcript renders exactly as the pre-release build did, apart from run timings.

pi install npm:@nguyenquangthai/pi-omp-theme@1.0.24
# For an existing unpinned installation:
pi update npm:@nguyenquangthai/pi-omp-theme

v1.0.23

One side margin, and a calmer welcome card

Everything the theme draws now sits on the same one-column margin that Pi uses. The welcome card is redesigned to match.

Changed

• Side margin. Pi keeps one column clear on each side of the transcript. Its outputPad setting controls this for messages and tool output, and its Working... row and prompt sit one column in. The theme had set that padding to zero for tool boxes, inline blocks, and markers, and it drew the status row and the ! bash block from the edge. As a result, its rows started at column 0 while Pi's started at column 1.
  • Transcript blocks now follow outputPad on both sides. This covers the inline ● markers and ⎿ rows, tool boxes in every chrome, custom message blocks, and the ! bash block. It includes the edit tool, which Pi renders without padding.
  • The status row and the welcome card keep one column on each side, like Pi's working row and prompt.
  • The Working... spinner is Pi's own row. When the theme's editor is in place, Pi draws it one column in. It now lines up with everything else instead of looking one column off.
  • The editor frame and rules still run edge to edge, as Pi's do, and clicks map as before.
• Welcome card.
  • It stops growing at 100 columns and sits on the same one-column margin.
  • There is now one blank row above it; before, there were two above and three below.
  • Its frame uses the theme's quiet border color.
  • Both columns open and close with a blank row, and the title lines up with the tips. An inset rule separates Tips, Tool providers, and Recent sessions.
  • Tips fit on one row.
  • Tool providers list core first, then the others by tool count. Each row shows the tool count and as many tool names as fit, with +N for the rest.
  • With more than four providers, the last row reads +N more and names the remaining providers. Before, they were dropped without notice.
  • Provider names drop the npm scope and the pinned version or git ref: npm:@scope/pi-teams@0.1.6 shows as pi-teams.
  • Long session titles are cut to fit, and their ages share one right-aligned column.
  • The title reads "Welcome back!" only when there is a recent session. The top border reads Pi v<version>.
  • The card keeps a fixed height, so it never forces Pi to replay the screen.
• Gallery. The README welcome image and the gallery preview, which is also the pi.dev package image, now show the new card.

Not covered

• Messages you type, and Pi's [Extensions] startup listing (shown when quietStartup is off), are drawn by Pi and keep Pi's layout.

How it stays contained

• The change is presentation only.
  • The theme no longer overrides Pi's padding with zero. It reads outputPad and applies it.
  • Every tool golden section is byte-identical to 1.0.22.
  • 18 message golden sections changed only by the margin: 9 inline-marker sections and 9 user-bash sections. They have the same words, re-wrapped for the right-hand column.

Verification

• CI: this repository has no configured GitHub Actions workflows, check-runs, or commit-status contexts for the release commit. The local release gates below all passed.
• npm ci and npm run check passed: typecheck, 426 unit/integration/golden tests, dependency boundaries, production build, and package smoke.
  • 11 tests are new: 8 for the welcome card and 3 for the side margin (status row, ! bash block in every chrome, and the edit tool in every chrome).
  • Each intermediate commit passes npm run check on its own.
• npm run test:e2e:readonly-tools: 25/25 packed-package CLI/RPC cases passed on Pi 0.99.1 with pi-hashline-edit-pro 4.5.1.
• npm publish --dry-run: the expected 7-file npm artifact (150.5 kB packed).
• Real TUI on Pi 1.1.0, with the Titanium theme and an isolated agent directory. Margins were read back from the terminal buffer.
  • Transcript: the claude-code, default, and light chrome at 80, 100, and 160 columns. Every theme-drawn row starts at column 1 and leaves at least one column on the right. This includes the Working... row, the status row, and the !echo hi block. Only the editor frame touches the edges.
  • Welcome card: at 64 columns it falls back to the compact header. At 80 and 100 it keeps one column on each side. At 140 it stops at 100 columns.
  • One measurement artifact: at 160 columns, the harness terminal (xterm.js, Unicode 6 widths) counts 📁 as one cell and leaves a stale cell at the row's end. Pi measures that row at 152–154 of the 159 columns available.

Tested on Windows x64 with Node 24.11.1. Linux/macOS runs were not part of this verification.

Install / update

Published on npm. Verified:

• the registry latest tag, gitHead (the release commit), tarball shasum, and the pi.image gallery URL;
• a clean install whose files match the release build byte for byte;
• a real Pi 1.1.0 run of the installed package in the claude-code and default presets:
  • the welcome card matches the pre-release build exactly;
  • the transcript margins match apart from run timings, with every theme-drawn row starting at column 1.

pi install npm:@nguyenquangthai/pi-omp-theme@1.0.23
# For an existing unpinned installation:
pi update npm:@nguyenquangthai/pi-omp-theme

v1.0.22

Table borders keep their color in extension messages

With the Titanium themes, a table cell ending in inline code painted the │ after it, the padding, and the row's right edge in the code color. It showed up in extension messages such as pi-teams results, and in expanded compaction, skill, and branch blocks. This release fixes that.

Fixed

• Cause. Titanium leaves customMessageText empty, which means the terminal's own text color. Pi's Markdown strips the default text style's escape from the end of each inline run. For an empty color that escape is the same \x1b[39m that closes inline code, so the code color stayed open to the end of the row. Pi's own dark theme has no empty colors, so it does not show there.
• Change. These blocks no longer pass a default text style when that color is the terminal's own. Inline code keeps its closing escape, and the text renders in the same color as before. A colored customMessageText is handled exactly as before.
• Not covered. Messages you type go through Pi's own component, which the theme does not draw. A table cell ending in inline code there still colors its border under Titanium.

How it stays contained

• Presentation only, in one function (createMarkdownBody). Every golden section is byte-identical to 1.0.21.

Verification

• CI: this repository has no configured GitHub Actions workflows, check-runs, or commit-status contexts for the release commit. The local release gates below all passed.
• npm ci and npm run check: typecheck, 415 unit/integration/golden tests, dependency boundaries, production build, and package smoke.
  • 5 tests are new: a table in boxed, light, and inline chrome, plus text color with an empty and with a colored customMessageText.
  • The three table tests fail with the change disabled.
• npm run test:e2e:readonly-tools: 25/25 packed-package CLI/RPC cases on Pi 0.99.1 with pi-hashline-edit-pro 4.5.1.
• npm publish --dry-run: the expected 7-file npm artifact (148.5 kB packed).
• Real TUI on Pi 1.1.0 with the Titanium theme and an isolated agent directory. A recorded pi-teams result (two teammates, a script table) was replayed as an extension message, and foreground colors were read back from the terminal buffer:
  • In the claude-code and default presets, only the 6 table rows with code cells change. The code color now covers only the code text.
  • The other 12 measured rows keep their 1.0.21 colors, and the message text is identical.

Tested on Windows x64 with Node 24.11.1. Linux/macOS runs were not part of this verification.

Install / update

Published on npm. Verified:

• the registry latest tag, gitHead (the release commit), and tarball shasum;
• a clean install whose files match the release build byte for byte;
• a real Pi 1.1.0 run of the installed package. The replayed pi-teams table renders exactly as the pre-release build did, in both presets.

pi install npm:@nguyenquangthai/pi-omp-theme@1.0.22
# For an existing unpinned installation:
pi update npm:@nguyenquangthai/pi-omp-theme

v1.0.21

Code blocks highlight again after resuming a session

After resuming, forking, or switching to a session, its ```text and ```yaml blocks (and code inside thinking) stayed dim and unhighlighted with the theme, while Pi without the theme highlights them. This release fixes that, and the README gallery now shows the block Pi logo.

Fixed

• Stale highlight cache. Pi registers a few syntax grammars at startup, loads the rest in the background, and then repaints. Blocks drawn before that (a resumed session draws its history immediately) fall back to the plain code-block color. The theme memoizes highlighting to keep streaming cheap, and it had cached that pre-load fallback and served it to the repaint. A result equal to the no-language fallback is no longer cached, so the repaint highlights it; highlighted results and blocks with no language are still served from the cache.

  Measured in Pi 1.1.0 with the Titanium theme, a resumed session, foreground colors read back from the terminal buffer (same result on two runs each):

  Block	1.0.20	1.0.20 with only the cache disabled	Pi without the theme	1.0.21
  ```text	dim #9ca3b0	default	default	default
  ```yaml	dim, unhighlighted	highlighted	highlighted	highlighted
  code in thinking	dim	default	default	default
  ```bash	default	default	default	default
  ``` (no language)	dim	dim	dim	dim

• Fenced blocks with no language keep Pi's mdCodeBlock color by design, exactly as Pi renders them without the theme; in Titanium that color is the muted #9ca3b0. That is a palette choice, not part of this fix.

Changed

• The README gallery shows the block Pi brand logo in the welcome card: media/welcome.png and the gallery-preview.png preview, which is also the pi.dev package image. Only the logo region of each image was redrawn, on the capture's own character grid; a pixel diff against the previous images shows no change outside it. Image URLs move to ?v=gallery-3 so cached copies refresh.

How it stays contained

• Presentation only. The highlighter Pi provides is unchanged; the theme only stops caching the results that can still change.
• Every golden section is byte-identical to 1.0.20.

Verification

• CI: this repository has no configured GitHub Actions workflows, check-runs, or commit-status contexts for the release commit. The local release gates below all passed.
• npm ci and npm run check: typecheck, 410 unit/integration/golden tests (3 new cache tests: a grammar that loads after the first render, settled blocks still served from the cache, a language that never loads; the first and third fail on 1.0.20), dependency boundaries, production build, and package smoke.
• npm run test:e2e:readonly-tools: 25/25 packed-package CLI/RPC cases on Pi 0.99.1 with pi-hashline-edit-pro 4.5.1.
• npm publish --dry-run: the expected 7-file npm artifact (148.0 kB packed).
• Real TUI runs on Pi 1.1.0 with a deterministic local provider and an isolated agent directory, claude-code preset: a fresh answer and the same session resumed with -c render text, bash, yaml, and thinking code exactly as Pi without the theme.

Tested on Windows x64 with Node 24.11.1. Linux/macOS runs were not part of this verification.

Install / update

Published on npm. The registry latest tag, gitHead (release commit), tarball shasum, a clean install whose bundle matches the release build byte for byte, and a real Pi 1.1.0 resume run of the installed package (text, yaml, and thinking code highlighted after -c) have been verified.

pi install npm:@nguyenquangthai/pi-omp-theme@1.0.21
# For an existing unpinned installation:
pi update npm:@nguyenquangthai/pi-omp-theme

v1.0.20

Brand logo on the startup screen, and spaced inline blocks

The welcome card now shows the block Pi in its brand colors, and inline chrome keeps a blank row between a text block and the thinking or text that follows it in the same message.

● Test passed.

● Checking provider inheritance

  Checking package parity

● Everything matches.

Changed

• The startup logo is the block Pi in its coral (#f09082), blue (#509bb9), and gold (#f0c055) brand colors, in the welcome card and in the compact header on narrow terminals. The silhouette and colors follow @quandev104/pi-style (MIT). It replaces the accent-gradient logo with box-drawing shadows.
  • The colors are fixed: every theme gets the same three, and only NO_COLOR keeps the logo as plain blocks. On a light terminal background the gold reads lighter than the other two, as in pi-style.
  • The welcome card keeps its size and layout; every compact-header row still fits its width.
  • The README gallery screenshots still show the previous logo.

Fixed

• Inline chrome (messages.assistantMarker or messages.thinkingSummary, both on in the claude-code preset): a text block followed by a thinking run, or by a second text block, in the same message painted flush against it, two ● rows touching. Models that interleave reasoning with short text, such as Codex, produce this order. Each ● entry now has the blank row the others have. Other presets keep Pi's spacing.

How it stays contained

• Presentation only. Pi's message layout is unchanged; the theme adds one blank row only between a text block and a marked block directly after it, before the markers are drawn.
• Every existing golden section is byte-identical to 1.0.19. New sections record the interleaved cases, including the same message without markers, which keeps Pi's native spacing.

Verification

• CI: this repository has no configured GitHub Actions workflows, check-runs, or commit-status contexts for the release commit. The local release gates below all passed.
• npm ci and npm run check: typecheck, 407 unit/integration/golden tests (9 more than 1.0.19: five for the logo — exact per-run colors, NO_COLOR, width fit at 80 to 8 columns, card height, startup wiring — and four interleaved-message goldens), dependency boundaries, production build, and package smoke.
• npm run test:e2e:readonly-tools: 25/25 packed-package CLI/RPC cases on Pi 0.99.1 with pi-hashline-edit-pro 4.5.1.
• npm publish --dry-run: the expected 7-file npm artifact (147.6 kB packed).
• Real TUI runs on Pi 1.1.0 with a deterministic local provider and an isolated agent directory, claude-code preset:
  • the welcome card at 110 columns and the compact header at 60 and 40 columns, with every logo cell's color read back from the terminal buffer (exact brand colors; the card frame keeps its own color);
  • a message of text, two reasoning summaries, and text: 1.0.19 paints the first text flush against the thinking row, 1.0.20 separates them.

Tested on Windows x64 with Node 24.11.1. Linux/macOS runs were not part of this verification.

Install / update

Published on npm. The registry latest tag, gitHead (release commit), tarball shasum, a clean install whose files match the release build byte for byte, and a real Pi 1.1.0 TUI run of the installed package on the claude-code preset (logo colors read back from the terminal, spaced interleaved message) have been verified.

pi install npm:@nguyenquangthai/pi-omp-theme@1.0.20
# For an existing unpinned installation:
pi update npm:@nguyenquangthai/pi-omp-theme

v1.0.19 — Every short list opens on Ctrl+O

Every short list opens on Ctrl+O

Lists that stop after their first few rows now expand like grep and diffs do, and a gh pr view body no longer offers a Ctrl+O that does nothing.

● Git status
  ⎿  9 modified · 1 untracked
     ├─ M  README.md
     ├─ M  file1.txt
     …
     └─ … 4 more files · Ctrl+O to expand

Fixed

• A gh pr view or gh issue view body longer than eight lines offered · Ctrl+O, but expanding showed nothing more. The body now expands.
• Every list that stops at a short head now opens on Ctrl+O: ls and find (the tools in boxed and light chrome, and through bash in every chrome), batches of reads and listings, git status, diff --stat, show --stat, log, and the commit, pull, merge, and reset cards, and gh pr and issue lists, checks, runs, and the jobs listed by gh run view (the gh run view --job log frame is unchanged). Collapsed lists look as before plus · Ctrl+O to expand on their … 4 more files row (inline bash ls/find carry it on the summary row, like the List and Find tools); expanded lists show up to tools.maxExpandedLines.

How it stays contained

• Presentation only. One shared budget decides how many rows a list paints collapsed and expanded, and offers Ctrl+O only when expanding paints rows the collapsed list leaves out; narrow rows keep it as · Ctrl+O.
• Nothing shown before is removed: every existing golden section is byte-identical to 1.0.18, and the new sections only add the hint and the expanded rows.

Verification

• CI: this repository has no configured GitHub Actions workflows, check-runs, or commit-status contexts for the release commit. The local release gates below all passed.
• npm ci and npm run check: typecheck, 398 unit/integration/golden tests (22 more than 1.0.18; seven new list fixtures run through the expand-hint property, and boxed batches get a direct test), dependency boundaries, production build, and package smoke.
• A mutation check (the budget ignoring the expanded state) fails exactly the seven new fixtures and the batch test.
• npm run test:e2e:readonly-tools: 25/25 packed-package CLI/RPC cases on Pi 0.99.1 with pi-hashline-edit-pro 4.5.1 (ripgrep supplied on PATH).
• npm publish --dry-run: the expected 7-file npm artifact (148.2 kB packed).
• Real TUI runs on Pi 1.1.0 with a deterministic local provider, an isolated agent directory, and a git repository with ten files, eight commits, and eight modified files, on the claude-code and claude presets at 110 and 40 columns: bash ls/find, the ls tool, git status, and git log show the hint collapsed, every row expanded, and one result gutter per inline block. The gh cards are covered by goldens and unit tests (the harness has no real gh output).

Tested on Windows x64 with Node 24.11.1. Linux/macOS runs were not part of this verification.

Install / update

Published on npm. The registry latest tag, gitHead (release commit), tarball shasum, a clean install whose bundle matches the release build byte for byte, and a real Pi 1.1.0 TUI run of the installed package on the claude-code preset (collapsed hint, expanded rows) have been verified.

pi install npm:@nguyenquangthai/pi-omp-theme@1.0.19
# For an existing unpinned installation:
pi update npm:@nguyenquangthai/pi-omp-theme

v1.0.18 — Truthful Ctrl+O and Claude Code touches

Truthful Ctrl+O, and three more Claude Code touches

Ctrl+O now appears only where expanding shows something new, and it stays readable on a narrow terminal. The claude-code preset gains a token count on the working row, Claude Code's edit sentences, and a prompt after an interrupted turn. /reload no longer leaves the transcript half-themed.

● Edit(src/auth.ts)
  ⎿  Updated src/auth.ts with 1 addition and 1 removal
     +1 −1 · 0.2s
● Grep(row in src)
  ⎿  12 matches in 1 file · Ctrl+O to expand
⣾ Working... (14s · ↓ 1.2k tokens · Escape to interrupt)

Added

• theme.workingTokens: the working row counts the run's output tokens, Working... (14s · ↓ 1.2k tokens · Escape to interrupt). Streamed text is estimated at about four characters a token until each message reports its real usage.
• tools.editSummary: inline file changes read like Claude Code's. An edit opens with Updated src/auth.ts with 1 addition and 1 removal above the existing +1 −1 · 0.2s row and diff; a write names its file, Wrote 3 lines to notes/todo.txt · 0.2s. Narrow rows shorten the sentence to Updated src/auth.ts and leave the write's path out rather than cut the run time.
• messages.interruptHint: an interrupted turn keeps Pi's notice and adds · What should the agent do instead?, both for an answer (Operation aborted) and for a tool run (Error: This operation was aborted, which is how Pi reports Esc during a tool).
• The claude-code preset turns all three on. They are off by default, so other presets render exactly as before, and each only adds to what was shown.

Fixed

• Ctrl+O no longer promises lines it cannot show. A diff (edit, quick edit, git diff) offered it when only unchanged context was folded, and expanding repainted the same rows; an expanded diff now shows all the context it has room for, so Ctrl+O and a click reveal the folded lines. Inline grep offered it when every match was already shown, and compaction, skill, and branch blocks when their body was empty or a single line that fits.
• Diffs read Pi's ... row (unchanged lines its edit diff leaves out) as a gap instead of a numbered line (10 ...), and split diffs number the new side correctly after a skipped run, after a change that opens the diff, and across the hunks of a git diff.
• Boxed grep results and grep commands run through bash offer Ctrl+O on their … 7 more matches row.
• On a narrow terminal the hint is no longer cut to Ctrl+O t…: a row that cannot fit Ctrl+O to expand shows the bare key (· Ctrl+O) and shortens its own text first, in every chrome.
• An expanded grep (the tool and grep/rg through bash) shows up to tools.maxExpandedLines rows instead of stopping at 24; collapsed previews keep their six-row cap.
• Inline chrome: grep, rg, ls, and find run through bash read like the Grep, List, and Find tools, and git and gh cards hang under the ⎿ gutter. A git diff no longer opens a second ⎿ halfway down its block, and an empty one no longer repeats no changes.
• git diff and git status render their cards on Windows with core.autocrlf on; Git's LF will be replaced by CRLF warnings made the parser fall back to raw text. Other warnings still fall back as before.
• /reload left the transcript half-themed: the reloaded copy found the previous copy's core patches still installed and fell back to Pi's native rendering while the retired copy kept rendering. The reloaded copy now takes the patches over, and widgets.hide changes apply on /reload.

How it stays contained

• Everything is presentation. The token counter only reads Pi's message events, the interrupt hint only changes the rendered notice row (the session and what the model sees are untouched), and the /reload fix only hands the theme's own core patches from the old copy to the new one.
• Property tests now fail on a Ctrl+O hint that adds nothing, on a block that expands with no hint, and on a second result gutter under one inline block, across boxed, light, and inline chrome at 80 and 36 columns.

Verification

• CI: this repository has no configured GitHub Actions workflows, check-runs, or commit-status contexts for the release commit. The local release gates below all passed.
• npm ci and npm run check: typecheck, 376 unit/integration/golden tests (64 more than 1.0.17), dependency boundaries, production build, and package smoke.
• npm run test:e2e:readonly-tools: 25/25 packed-package CLI/RPC cases on Pi 0.99.1 with pi-hashline-edit-pro 4.5.1 (ripgrep supplied on PATH).
• npm publish --dry-run: the expected 7-file npm artifact (147.3 kB packed).
• Real TUI runs on Pi 1.1.0 with a deterministic local provider and an isolated agent directory, on the claude-code and claude presets at 110 and 40 columns: token counts, edit and write sentences, the interrupt prompt for answers and tool runs, Ctrl+O and click expansion of diffs and grep, hints kept at 40 columns, inline bash grep/ls/find and git status/diff panels with one gutter, a git repository with core.autocrlf, and /reload keeping the themed transcript.

Tested on Windows x64 with Node 24.11.1. Linux/macOS runs were not part of this verification.

Install / update

Published on npm. The registry latest tag, gitHead (release commit), tarball shasum, a clean install whose bundle matches the release build byte for byte, and a real Pi 1.1.0 TUI run of the installed package on the claude-code preset have been verified.

pi install npm:@nguyenquangthai/pi-omp-theme@1.0.18
# For an existing unpinned installation:
pi update npm:@nguyenquangthai/pi-omp-theme

v1.0.17 — Hide extension widgets

Hide chosen extension widgets

widgets.hide keeps chosen extension widgets off screen. The extension keeps running; only its widget is not drawn. With the claude-code transcript, pi-todo's checklist already appears in the transcript, so its pinned Updated Plan box above the editor can go:

{
  "piOmpTheme": {
    "widgets": { "hide": ["pi-todo"] },
    "compatibility": { "allowCorePatches": true }
  }
}

Added

• widgets.hide: a list of extension widget keys to keep off screen (pi-todo uses pi-todo). Other widgets are untouched, and the list is empty by default, so nothing changes unless it is set.
• Needs compatibility.allowCorePatches. /pi-omp-theme doctor reports it as Widgets. /todos and pi-todo's tools keep working. Changes to the list take effect when Pi restarts.

How it stays contained

• The filter wraps InteractiveMode.setExtensionWidget through the existing identity-certified core patch registry. It is installed only when the list is non-empty, falls back to native rendering on an unrecognised Pi build, and yields if another extension already owns that method.

Verification

• CI: this repository has no configured GitHub Actions workflows, check-runs, or commit-status contexts for the release commit. The local release gates below all passed.
• npm ci and npm run check: typecheck, 312 unit/integration/golden tests (4 new for the widget filter), dependency boundaries, production build, and package smoke.
• npm run test:e2e:readonly-tools: 25/25 packed-package CLI/RPC cases on Pi 0.99.1 with pi-hashline-edit-pro 4.5.1 (ripgrep supplied on PATH).
• npm publish --dry-run: the expected 7-file npm artifact (141.7 kB packed).
• Real TUI runs on Pi 1.1.0 with pi-todo, a deterministic local provider, and an isolated agent directory: without widgets.hide the Updated Plan box shows and doctor reports Widgets OFF; with ["pi-todo"] the box is gone, the transcript checklist and /todos still work, and doctor reports Widgets OK.

Tested on Windows x64 with Node 24.11.1. Linux/macOS runs were not part of this verification.

Install / update

Published on npm. The registry latest tag, gitHead (release commit), tarball shasum, a clean install whose bundle matches the release build byte for byte, and a real Pi 1.1.0 TUI run of the installed package with widgets.hide: ["pi-todo"] have been verified.

pi install npm:@nguyenquangthai/pi-omp-theme@1.0.17
# For an existing unpinned installation:
pi update npm:@nguyenquangthai/pi-omp-theme