Why there are no emoji in envsec's output

A terminal is a grid

A terminal draws text into a grid of cells. Every program that writes to it, and every line editor that moves the cursor around in it, has to know how many cells each character takes. The usual answer comes from wcwidth(3): 0 for combining marks, 1 for most characters, 2 for wide ones such as CJK ideographs.

The catch is that there is no single wcwidth. Your libc has one, which shells and line editors usually call. Terminal multiplexers and terminal emulators often ship their own tables. Each is built from some version of the Unicode data, and the versions don't always agree. Plain ASCII never trips over this. Emoji do, all the time.

Four ways an emoji breaks the grid

• Width tables. Unicode's East_Asian_Width property (UAX #11) classifies characters as Wide (W), Narrow (Na), Neutral (N) or Ambiguous (A), among others. Since Unicode 9.0, emoji that display as emoji by default are W. A component that still uses an older table counts them as 1 cell while the terminal draws 2.
• Variation selectors. Some characters, like 🛡 (U+1F6E1) and ⚠ (U+26A0), have text presentation by default. Add U+FE0F (VARIATION SELECTOR-16) and they become emoji. The selector itself has width 0, so wcswidth still says 1, while many terminals paint a two-cell colour glyph.
• ZWJ sequences. 👩‍💻 is three code points joined by a ZERO WIDTH JOINER. Summing per-code-point widths gives 4. A terminal that knows the sequence draws one 2-cell glyph; one that doesn't draws two.
• Fonts. Monospace programming fonts rarely include emoji, so the terminal falls back to a colour emoji font whose glyph doesn't fit the cell. Some terminals scale it down, some let it overflow into the next cell.

Here is what macOS's own libc reports for a few of them:

The 1s next to the VS16 sequences and the 4 next to the ZWJ sequence are where libc and a terminal that draws colour emoji are likely to disagree. When one line in a list is off by a cell, the columns after it no longer line up, and a line editor that guessed wrong puts the cursor in the wrong place.

What I changed in envsec

envsec's first icon set had 🔑 for keys, 🔒 for locks, 📁 for contexts, 🛡 for the doctor and ✅ for success. In March 2026 I replaced every emoji in the set with a geometric Unicode glyph in one commit (6709620da). An excerpt of the diff:

-  key: yellow("🔑"), // U+1F511
-  lock: green("🔒"), // U+1F512
-  folder: blue("📁"), // U+1F4C1
-  shield: green("🛡"), // U+1F6E1
-  check: green("✅"), // U+2705
-  broom: yellow("🧹"), // U+1F9F9
+  key: yellow("◆"), // U+25C6
+  lock: green("■"), // U+25A0
+  folder: blue("▸"), // U+25B8
+  shield: green("◈"), // U+25C8
+  check: green("✔"), // U+2714
+  broom: yellow("~"), // tilde

The same commit added a rule to the agent instructions in the repo: all icons live in one icons object (today in packages/core/src/ui.ts), every glyph carries a comment with its code point, each is wrapped in its colour function, and emoji are not allowed. Here is the complete set:

None of these has the Emoji_Presentation property, and envsec never emits U+FE0F. The source tree has no variation selectors at all. Secret values can still contain emoji; envsec only declines to add its own.

Not a perfect set

I'd like to say these glyphs are always one cell. They aren't. 13 of the 24 distinct glyphs, including → ● ◆ ■ ▲ and ×, are East Asian Ambiguous. Ambiguous characters are one cell in most Western setups and two cells in many CJK ones, and several terminals (and Vim, via ambiwidth) let you choose. Four of them, ✔ ✖ ▪ and ▶, still carry the Emoji property: their default is text, but a renderer that ignores presentation defaults could still pick an emoji font.

The trade is between failure modes. An emoji depends on the Unicode version, the font, the selector and the terminal, and can be wrong in a different way on every line. An ambiguous-width glyph depends on one setting, and when it is wrong, every line is wrong by the same amount.

Colour, NO_COLOR and pipes

Colour is plain ANSI SGR escapes, decided once per output stream when ui.ts loads:

export const isColorEnabled = (
  stream: { readonly isTTY?: boolean },
  env: NodeJS.ProcessEnv = process.env
): boolean => {
  if (env.NO_COLOR) {
    return false;
  }
  const force = env.FORCE_COLOR;
  if (force !== undefined) {
    return force !== "0" && force !== "false";
  }
  return stream.isTTY ?? false;
};

const createUi = (useColor: boolean) => {
  const ansi = (code: string) => (text: string) =>
    useColor ? `\u001B[${code}m${text}\u001B[0m` : text;
  // ... colours, icons and helpers built from ansi()
};

// stdout for command output, stderr for warnings and errors
export const { green, red, icons /* ... */ } = createUi(
  isColorEnabled(process.stdout)
);
export const stderrUi = createUi(isColorEnabled(process.stderr));

That gives three rules, in this order:

• NO_COLOR set to any non-empty value turns colour off, as the NO_COLOR convention asks. An empty NO_COLOR= is ignored, which also matches it.
• FORCE_COLOR turns it on, unless it is 0 or false, which turn it off. That is how Node.js itself reads the variable.
• Otherwise colour is on only when the stream being written is a TTY: stdout for command output, stderr for warnings and errors.

Piping drops the escapes but keeps the glyphs, so the output of envsec list | cat is still readable:

▸ myapp.dev  (3 secrets)
▸ myapp.prod  (2 secrets)

Two rough edges I found while checking this, both fixed in envsec 1.1.3. FORCE_COLOR=0 used to force colour on, because the check only tested for a non-empty string, while libraries such as supports-color treat 0 as off. And there was one TTY test, on stdout, even for errors written to stderr: run envsec in a terminal with 2> err.log and the log file got escape codes, while envsec env | … printed its warnings to the terminal without colour. Each stream now gets its own palette. Scripts that want clean bytes can still set NO_COLOR=1 or use --json where a command supports it.

In short

Emoji width depends on the Unicode version, the font, variation selectors and joiners, and the terminal, and the program printing them controls none of those. envsec uses 24 geometric glyphs with no emoji presentation, wrapped in ANSI colours that switch off with NO_COLOR or a pipe. They still have one known weak spot, ambiguous width, but they fail the same way on every line. For the other side of small CLI details, see how envsec completes contexts and keys in bash, zsh and fish.