← Blog

Smart CLI Autocomplete: Tag-Substrate Shell Completion in sigilOS

June 22, 2026 · sigil-apps · Sigil-Docs
apps terminal smart-folders shell 0.5.x

sig-sh, the sigilOS shell, now has two tiers of autocomplete — both powered by the same engine that drives Smart Folders. Tab-completion in sigilOS isn't a list of filenames; it's a live tag query against the capability-scoped FS substrate, returning only files the current session can actually access. (Apps ce9dc0a, a564dc6)


Pt 1: Command and flag completion

pt1 Command / flag completion + hint-nav

Tab on a partial command name gives the completion candidates from the shell's built-in command table and the EL0 app registry. Tab on a flag (-- prefix) completes flag names from the active command's flag table. A second Tab cycles candidates; hint-nav (arrow keys on the inline hint) moves through the list without committing. (Apps ce9dc0a, Director-greenlit)

The completion engine lives entirely in apps/term/term.sg. It has no knowledge of the filesystem at this layer — command names come from a static table, flags from per-command descriptors. The result is a shell that already knows every built-in verb and every registered EL0 app before the user types a single character.

sig-sh terminal in Lumen WM window
sig-sh as a Lumen WM window — the AA terminal shipping in 0.5.0

Pt 2: Path/file completion via the tag substrate

pt2 Tag-substrate path completion (fs_query syscall 91)

Tab on a path prefix issues a live fs_query (syscall 91) against the FS tag substrate — the same query the Smart Folders column browser runs when you drill a tag. The shell sends the prefix as a tag filter, and the substrate returns items that match, ranked by recency and tag relevance. Only items the session's Cap<FS> can reach appear in the completion list. (Apps a564dc6)

The key wire: fs_query=91 is routed through the Kernel's host.sg (the same syscall the column browser calls). The shell does not walk a directory tree — it does what the tag substrate does: query by prefix, get ranked items. The completion list and the column browser's first-column contents are the same query run from two different surfaces.

sig-sh$ cat /docs/proj<TAB>
→ fs_query(prefix="proj", cap=session_slot)
→ ["/docs/project-charter", "/docs/progress-notes"]

sig-sh$ cat /docs/proj[ect-charter, ect-notes]  ← inline hint-nav
sig-sh path completion via tag substrate
Tab path completion via fs_query syscall 91 — only cap-accessible files appear

The security model: absent, not greyed

The tag substrate's cap-scoping applies here exactly as it does for Smart Folders: fs_query is brokered — the kernel injects the login-bound session slot on every call, and items the session can't access are absent from the result set, not greyed. A restricted session sees a shorter completion list, not a greyed-out one — because greying would be a capability-information leak.

This means the shell's autocomplete is structurally capability-secure: the completions you see are exactly the files you can open, with no ambient read of the directory tree.


One engine, two surfaces

SurfaceQuery pathSyscallResult
Smart Folders column browser tagfs.sg → fs_tag_children 92 Column items in tag hierarchy
Tag well prefix-autocomplete tagfs.sg → fs_tag_list 94 Tag name completions
Shell path completion term.sg → fs_query 91 Files matching prefix, ranked

The same indexed substrate (the FS tag engine in fs/metal/tagidx.sg) serves all three. Any file you tag is immediately reachable from the column browser, the tag well, and the shell's Tab key — one substrate, three access surfaces, one cap-scoping model across all of them.