Feature: Vault-native shell history memory with AI indexing and zsh plugin

[senolcolak]

Summary

Introduce RustShare Shell Memory: a vault-native shell history system that captures terminal commands with operational context, stores them securely in the RustShare vault, exposes them through web/API/SSH-style access, and reindexes them for search, AI/RAG, summaries, and runbook generation.

This should not be implemented as a simple .bash_history or .zsh_history file sync. The goal is to turn shell history into durable, searchable operational memory.

Problem

Current shell history is usually local, unstructured, hard to search across machines, and disconnected from project/workspace context. It also often contains sensitive data, so blindly syncing raw history files would be unsafe.

RustShare already aims to become a durable memory layer for files, notes, technical work, and company/project knowledge. Shell history is a natural extension of that idea because many infrastructure decisions, troubleshooting steps, and operational procedures happen in the terminal first.

Goals

• Capture shell commands with useful context.
• Store shell history inside the RustShare vault in a structured and secure way.
• Allow searching history across multiple machines, projects, hosts, and sessions.
• Allow access from machines where no permanent RustShare client is installed.
• Reindex shell history for semantic search, AI summaries, and RAG.
• Generate reusable runbooks from successful command sequences.
• Provide a zsh plugin as the first capture integration.
• Keep the implementation security-first, with strong redaction and privacy controls.

Non-goals for the first version

• Do not replace all shell history tools immediately.
• Do not build a full Atuin clone in the first iteration.
• Do not sync raw .bash_history or .zsh_history files without filtering.
• Do not execute remote commands from RustShare UI.
• Do not make shell history shared by default.

Prior art and licenses

Existing tools validate this product direction:

Tool	Purpose	License note	RustShare relevance
Atuin	Encrypted shell history sync/search	Core project is MIT licensed	Strong prior art; possible future import/export integration. Do not vendor code in MVP unless license notices are handled.
fzf	Fuzzy terminal search UI	MIT licensed	Useful UX reference for terminal search.
McFly	Smarter shell history search	License must be verified before any reuse	Useful concept reference for context-aware ranking.
zsh history sync plugins	zsh-specific history sync using Git/GPG or similar	Usually permissive, but verify per project	Useful reference for shell plugin behavior and encrypted sync patterns.

RustShare should differentiate by treating shell history as vault-native operational memory, not just synchronized command recall.

Recommended policy:

• Build a native RustShare collector first.
• Support Atuin import later.
• Mention Atuin as prior art, not as a dependency.
• Keep any RustShare shell plugin under the same license strategy as RustShare unless intentionally separated.

Proposed architecture

1. Capture layer

Start with a small zsh plugin that captures commands using shell hooks and forwards events to a RustShare shell collector binary.

Example data to capture:

command: ceph osd tree
cwd: /home/user/projects/customer-a
host: os81
shell: zsh
exit_code: 0
duration_ms: 120
timestamp: 2026-06-16T00:11:22+02:00
git_repo: kubedoio/rustshare
git_branch: main
kube_context: optional
ssh_target: optional
tags:
  - ceph
  - troubleshooting

The zsh plugin should stay thin. The main logic should live in a Rust binary, for example:

rustshare-shell capture
rustshare-shell search
rustshare-shell sync
rustshare-shell redact
rustshare-shell pause 30m
rustshare-shell forget last

2. Local buffer / offline support

The collector should work offline and buffer locally.

Possible local store:

~/.local/share/rustshare-shell/history.sqlite

or platform-specific equivalent.

The client should sync later when RustShare is reachable.

3. Vault storage model

Do not store everything as one huge Markdown file.

Use structured storage as source of truth and generate Markdown views where useful.

Possible vault layout:

/vault/
  .rustshare/
    shell-history/
      index.sqlite
      redaction-rules.yaml
      embeddings/
  Shell History/
    2026/
      06/
        2026-06-16.md
    hosts/
      os81.md
      macbook-pro.md
    projects/
      rustshare.md
      customer-a.md

Source of truth options:

• SQLite
• JSONL event stream
• internal RustShare artifact model

Generated Markdown views should be human-readable but not the only authoritative data source.

4. Search and access without local client

Support access modes that do not require permanent client installation:

Web UI

A RustShare web view for shell history:

/shell-history
/shell-history/hosts/:host
/shell-history/projects/:project
/shell-history/sessions/:session

Search examples:

ceph osd purge
host:os81 exit:0
project:rustshare kubectl
after:2026-06-01 before:2026-06-16
failed:true

API

Provide authenticated API search:

curl -H "Authorization: Bearer <token>" \
  "https://rustshare.example.com/api/shell-history/search?q=ceph+osd"

Temporary bootstrap access

Optional one-time bootstrap command:

curl -s https://rustshare.example.com/shell/bootstrap | sh

This should be disabled by default or gated behind short-lived tokens.

SSH-style access, future idea

Possible future UX:

ssh history@rustshare.example.com search "rook ceph"
ssh history@rustshare.example.com last --host os81
ssh history@rustshare.example.com suggest "remove osd cleanly"

This would allow shell-history search from machines without installing a RustShare client.

AI / RAG behavior

Shell history should be indexed at multiple levels:

Raw command index

For exact search:

ceph osd purge osd.24 --yes-i-really-mean-it

Semantic command index

Generate normalized semantic text for embeddings, for example:

User removed Ceph OSD 24 from host os81 using ceph osd purge. The command succeeded. Context: Ceph maintenance, OSD removal, storage operations.

Session index

Group commands into sessions:

session:
  host: os81
  start: 2026-06-16T00:10:00+02:00
  end: 2026-06-16T00:42:00+02:00
  topic: Ceph OSD removal
  outcome: successful

Project index

Infer project from:

• cwd
• Git remote
• Git branch
• RustShare workspace
• host
• kube context
• ssh target

AI use cases

RustShare AI should be able to answer questions like:

• “Show me the commands I used last time to remove Ceph OSDs cleanly.”
• “Find all commands related to Rook-Ceph upgrade from 18.2.4 to 19.2.3.”
• “Create a runbook from my successful commands on os81 and os82.”
• “Which commands failed repeatedly during the OpenStack deployment?”
• “Summarize what I did yesterday on the customer-a cluster.”

Security requirements

This feature must be private and security-first.

Local redaction before upload

Never upload obviously sensitive commands by default.

Examples to block or redact:

• password=
• token=
• secret=
• AWS_SECRET_ACCESS_KEY
• PRIVATE_KEY
• sshpass
• mysql -p...
• psql postgresql://user:pass@...
• kubectl create secret ...
• commands starting with a leading space, if the shell is configured to treat that as private

Server-side redaction

Server-side validation should run even if the local client missed something.

User controls

Required controls:

rustshare-shell pause 30m
rustshare-shell disable
rustshare-shell enable
rustshare-shell forget last
rustshare-shell redact "token=..."
rustshare-shell status

Privacy defaults

• Shell history is private by default.
• No team sharing by default.
• No AI indexing of shell history unless enabled for the workspace/user.
• Allow disabling AI indexing per host, project, workspace, or command pattern.
• Allow command-level delete/redaction.

Proposed MVP phases

MVP-1: Capture and vault storage

• zsh plugin
• Rust collector CLI
• local SQLite buffer
• redaction rules
• manual sync to RustShare vault
• basic web UI search
• delete/redact command
• generated Markdown views

MVP-2: AI indexing

• semantic indexing
• session grouping
• AI search
• daily/session summaries
• generate runbook from selected commands

MVP-3: Clientless access

• web UI improvements
• authenticated REST API
• short-lived access tokens
• optional SSH-style search endpoint

MVP-4: Compatibility

• Bash support
• Fish support
• Nushell support
• import from .zsh_history
• import from .bash_history
• Atuin import support
• export to Markdown/JSONL

Acceptance criteria for MVP-1

• zsh plugin captures command, timestamp, cwd, host, shell, exit code, and duration.
• Collector stores events locally when offline.
• Collector syncs events into RustShare vault.
• Redaction rules prevent obvious secrets from being uploaded.
• User can pause, disable, and re-enable capture.
• User can delete or redact captured commands.
• RustShare web UI can search shell history by command text.
• RustShare web UI can filter by host, project, date, and exit code.
• Shell history is private by default.
• Generated Markdown views are available but do not replace the structured source of truth.
• No unrelated Notes, Files, or workspace behavior is changed.

Open questions

• Should the source of truth be SQLite, JSONL, or RustShare’s internal artifact database?
• Should AI indexing be opt-in globally, per workspace, or per vault?
• Should RustShare initially support Atuin import, or leave it for a later milestone?
• Should the zsh plugin be published as a separate package/repository?
• Should shell history be treated as a special vault object type or as normal artifacts with metadata?
• Should SSH-style search be part of MVP-1 or a later phase?

Suggested positioning

Do not market this as simple shell history sync.

Better positioning:

RustShare Shell Memory turns terminal work into durable operational knowledge.

Alternative:

Your commands become searchable runbooks, incident timelines, and AI-ready infrastructure memory.

[senolcolak]

the terminal database should be accessible from thell integrations directly. like when the user enters to a new machine and wants to get the whole history access they just need to "install zsh run this oneliner to access via token" the integration will provide a token (valid for 5 min) . so the whole process of shell node adding would take less than 30 seconds to get your all shell history on your new shell.
[Future Enhacements] One other goal of this function is to integrate the shell history database to other knowledge RAG documentations to provide suggestions on the shell