RepoPilotOpen in app β†’

lencx/Noi

πŸš€ Less chaos. More flow.

Mixed

Slowing β€” last commit 3mo ago

weakest axis
Use as dependencyFailing

no license β€” legally unclear; no tests detected

Fork & modifyFailing

no license β€” can't legally use code; no tests detected

Learn fromHealthy

Documented and popular β€” useful reference codebase to read through.

Deploy as-isFailing

no license β€” can't legally use code

  • βœ“Last commit 3mo ago
  • βœ“14 active contributors
  • βœ“CI configured
  • ⚠Slowing β€” last commit 3mo ago
  • ⚠Single-maintainer risk β€” top contributor 81% of recent commits
  • ⚠No license β€” legally unclear to depend on
  • ⚠No test directory detected
What would change the summary?
  • β†’Use as dependency Failing β†’ Mixed if: publish a permissive license (MIT, Apache-2.0, etc.)
  • β†’Fork & modify Failing β†’ Mixed if: add a LICENSE file
  • β†’Deploy as-is Failing β†’ Mixed if: add a LICENSE file

Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests

Informational only. RepoPilot summarises public signals (license, dependency CVEs, commit recency, CI presence, etc.) at the time of analysis. Signals can be incomplete or stale. Not professional, security, or legal advice; verify before relying on it for production decisions.

Earn the β€œHealthy” badge

Current signals for lencx/Noi are Mixed. The embed flow is reserved for repos showing Healthy signals β€” the rest stay informational on this page so we're not putting a public call-out on your README. Address the items in the What would change the summary? dropdown above, then return to grab the embed code.

Common quick wins: green CI on default branch, no Critical CVEs in dependencies, recent commits on the default branch, a permissive license, and a published README.md with a quickstart.

Onboarding doc

Onboarding: lencx/Noi

Generated by RepoPilot Β· 2026-05-06 Β· Source

Agent protocol

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

  1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale β€” STOP and ask the user to regenerate it before proceeding.
  2. Treat the AI Β· unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
  3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/lencx/Noi shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything β€” but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

Verdict

WAIT β€” Slowing β€” last commit 3mo ago

  • Last commit 3mo ago
  • 14 active contributors
  • CI configured
  • ⚠ Slowing β€” last commit 3mo ago
  • ⚠ Single-maintainer risk β€” top contributor 81% of recent commits
  • ⚠ No license β€” legally unclear to depend on
  • ⚠ No test directory detected

<sub>Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests</sub>

Verify before trusting

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live lencx/Noi repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale β€” regenerate it at repopilot.app/r/lencx/Noi.

What it runs against: a local clone of lencx/Noi β€” the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in lencx/Noi | Confirms the artifact applies here, not a fork | | 2 | Default branch main exists | Catches branch renames | | 3 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 4 | Last commit ≀ 121 days ago | Catches sudden abandonment since generation |

<details> <summary><b>Run all checks</b> β€” paste this script from inside your clone of <code>lencx/Noi</code></summary>
#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of lencx/Noi. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/lencx/Noi.git
#   cd Noi
#
# Then paste this script. Every check is read-only β€” no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of lencx/Noi and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "lencx/Noi(\\.git)?\\b" \\
  && ok "origin remote is lencx/Noi" \\
  || miss "origin remote is not lencx/Noi (artifact may be from a fork)"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "configs/noi.conf.json" \\
  && ok "configs/noi.conf.json" \\
  || miss "missing critical file: configs/noi.conf.json"
test -f "locales/noi.lang.json" \\
  && ok "locales/noi.lang.json" \\
  || miss "missing critical file: locales/noi.lang.json"
test -f "website/docusaurus.config.ts" \\
  && ok "website/docusaurus.config.ts" \\
  || miss "missing critical file: website/docusaurus.config.ts"
test -f "website/sidebars.ts" \\
  && ok "website/sidebars.ts" \\
  || miss "missing critical file: website/sidebars.ts"
test -f ".github/workflows/deploy.yml" \\
  && ok ".github/workflows/deploy.yml" \\
  || miss "missing critical file: .github/workflows/deploy.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 121 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~91d)"
else
  miss "last commit was $days_since_last days ago β€” artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) β€” safe to trust"
else
  echo "artifact has $fail stale claim(s) β€” regenerate at https://repopilot.app/r/lencx/Noi"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

</details>

TL;DR

Noi is a desktop application (built with TypeScript/Tauri) that reimagines browser-like workflows for AI chat interactions, emphasizing session isolation, multi-window management, and local-first data storage. It solves the chaos of juggling multiple AI conversations and contexts by providing interaction-first UI, prompt management, built-in terminal integration, and a CLI interface for programmatic control from AI coding assistants. Likely a Tauri desktop app with TypeScript frontend (7639 lines) and minimal custom CSS (1478 lines). Configs in configs/ directory (noi.conf.json, noi.space.json, noi_awesome.json) suggest modular configuration. Extensive locales/ structure (20+ languages with shared noi.lang.json) indicates i18n-first design. No visible monorepo structure β€” appears to be a single application with config-driven extensibility.

Who it's for

AI/LLM power users, developers using Claude/ChatGPT/Gemini CLI tools, technical teams who need isolated workspaces and local data control, and users who want to organize and reuse prompts across multiple AI sessions without cloud dependency.

Maturity & risk

Actively developed (v1.1.0 released); has GitHub Actions CI/CD pipeline (deploy.yml), extensive i18n support across 20+ languages, and a community Discord. Not yet 1.0 (pre-release maturity), so breaking changes are possible, but the core feature set is functional and the project shows steady iteration.

Single maintainer (lencx) with no visible test suite or test directory in the file listing creates maintenance risk. Dependency count appears moderate (Tauri/React stack), but no lock file data visible limits assessment. The 20+ locale files suggest organic growth but also potential localization maintenance burden. Desktop app distribution and Tauri updates can introduce platform-specific breakage.

Active areas of work

Active development toward stable release; GitHub Actions workflow exists (deploy.yml), suggesting automated builds and releases. The existence of multiple config files and the extensions/ README suggest ongoing work on extensibility. Multi-language support across 20+ locales shows community growth and localization efforts.

Get running

git clone https://github.com/lencx/Noi.git
cd Noi
npm install
npm run dev

(Note: Actual dev script not visible in provided config; check root package.json for 'dev' vs 'start' vs Tauri-specific commands like 'tauri dev')

Daily commands:

npm install
npm run dev

Note: Actual dev/start commands are not visible in the provided package.json snippet (which is for the website/ Docusaurus component, not the main app). Check root package.json for correct command β€” likely tauri dev or npm run tauri dev.

Map of the codebase

  • configs/noi.conf.json β€” Primary application configuration file that defines core settings, API endpoints, and feature flags used across the Noi desktop application.
  • locales/noi.lang.json β€” Master language configuration defining all supported locales and language metadata; required for understanding multi-language support architecture.
  • website/docusaurus.config.ts β€” Documentation site configuration using Docusaurus 3.0; entry point for all website build and deployment processes.
  • website/sidebars.ts β€” Documentation navigation structure; defines the information architecture and content hierarchy for all docs pages.
  • .github/workflows/deploy.yml β€” CI/CD pipeline definition for automated deployment; critical for understanding how changes flow to production.
  • extensions/README.md β€” Extension system documentation; explains how developers add custom functionality and plugins to Noi.
  • README.md β€” Project overview with feature set, positioning, and basic setup; essential context for all contributors.

How to make changes

Add a new language translation

  1. Create a new language directory following ISO 639-1 format (e.g., 'it' for Italian) (locales/[locale-code]/)
  2. Copy and translate the English template to the new language (locales/[locale-code]/app.json)
  3. Register the new locale in the master language configuration (locales/noi.lang.json)
  4. If adding documentation translation, create language subdirectory in i18n config (website/i18n/[language-code]/docusaurus-plugin-content-blog/)

Add a new documentation page

  1. Create a new markdown file in the docs directory with frontmatter metadata (website/docs/[page-name].md)
  2. Register the new page in the documentation sidebar structure (website/sidebars.ts)
  3. For localized versions, add translated content to i18n subdirectories (website/i18n/zh-CN/docusaurus-plugin-content-blog/[page-name].md)

Create a new application configuration preset

  1. Create a new JSON configuration file following the naming pattern (configs/noi.[preset-name].json)
  2. Define configuration schema with settings, features, and workspace defaults (configs/noi.[preset-name].json)
  3. Document the preset in the configuration README if needed (configs/README.md)

Develop a custom extension

  1. Review the extension development guidelines and API surface (extensions/README.md)
  2. Create extension manifest and entry point in extensions directory (extensions/[extension-name]/manifest.json)
  3. Package and distribute the extension following the documented format (extensions/[extension-name]/index.js)

Traps & gotchas

  1. Tauri build prerequisites: Requires Rust toolchain, system dependencies (GTK on Linux, MSVC on Windows, Xcode on macOS) β€” not just npm install. 2. Config precedence unclear: Multiple config files (noi.conf.json, noi.space.json, noi_awesome.json) suggest layered config; order of precedence and override behavior not documented in file list. 3. Locale file synchronization: 20+ locale files must stay synchronized with noi.lang.json β€” missing translations could break UI. 4. Desktop app caching: Built apps may cache data in user directories; development iteration requires cache clearing.

Architecture

Concepts to learn

  • Session Isolation β€” Core architectural concept in Noi β€” keeping separate AI chat contexts clean and predictable is the primary innovation; understanding how state is scoped per session is critical to modifying the app
  • Multi-Window Management β€” Noi's unique selling point is parallel workspace windows; contributors need to understand window lifecycle, state synchronization, and IPC (Inter-Process Communication) between windows
  • Local-First Data Architecture β€” Noi stores history, prompts, and settings on-device rather than cloud; understanding data persistence, migration, and offline-first patterns is essential for feature development
  • i18n (Internationalization) β€” Noi has 20+ language files; adding features requires string extraction to JSON and locale syncing β€” understanding the i18n framework and tool chain is mandatory for UI changes
  • Tauri Inter-Process Communication (IPC) β€” Multi-window + local commands (terminal integration) require async communication between Rust backend and JavaScript frontend; essential for understanding how CLI and UI coordinate
  • Configuration-Driven Application Design β€” Multiple JSON config files (noi.conf.json, noi.space.json) suggest behavior is externalized from code; understanding config schema and loading order is critical for feature toggles and customization
  • Desktop App Distribution & Signing β€” GitHub Actions deploy.yml suggests automated builds for multiple platforms; understanding code signing, auto-updates, and platform-specific packaging (DMG, MSI, AppImage) matters for releases

Related repos

  • openai/gpt-engineer β€” CLI-first AI coding tool that shares Noi's goal of improving AI-assisted workflows; potential integration target for Noi CLI
  • continuedev/continue β€” IDE extension for Claude/ChatGPT that manages AI sessions and prompts; similar problem space and potential collaboration on prompt management standards
  • tauri-apps/tauri β€” The underlying desktop runtime framework; essential for understanding Noi's architecture and build process
  • vercel/ai β€” Lightweight AI SDK for prompt chaining and session management; architectural inspiration or potential alternative approach to Noi's prompt system
  • lencx/ChatGPT β€” Likely the predecessor or spiritual ancestor of Noi; same author exploring desktop AI interfaces

PR ideas

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive i18n validation and testing for locales/

The repo supports 24+ languages (ar, bn, de, en, es, fa, fr, hi, hu, id, it, ja, ko, ms, pa, pl, pt, ru, sw, th, tr, ur, vi, zh-Hans, zh-Hant) but has no visible test suite validating that all locale files have complete key coverage, proper JSON syntax, or consistency with the base language (en). This prevents translator PRs from breaking the build and ensures quality across all supported languages.

  • [ ] Create website/tests/locales.test.ts to validate all locales/ JSON files match the en/app.json key structure
  • [ ] Add checks for missing keys, extra keys, and JSON syntax errors across all language files
  • [ ] Integrate test into CI pipeline via .github/workflows/deploy.yml to catch locale regressions
  • [ ] Document the validation rules in locales/README.md for future translators

Add GitHub Actions workflow for Docusaurus website build validation

The repo has a website/ folder with Docusaurus 3.0.1 and Tailwind CSS but .github/workflows/deploy.yml likely only handles the main app. There's no visible CI to catch broken documentation builds, TypeScript errors, or broken links before merge. This would catch issues early when docs or MDX files are modified.

  • [ ] Create .github/workflows/website-build.yml to run 'npm ci && npm run build && npm run typecheck' in the website/ directory on PRs
  • [ ] Add step to lint Markdown/MDX files in website/docs using a tool like markdownlint-cli
  • [ ] Configure workflow to run on changes to website/, locales/, and website/package.json
  • [ ] Document the website development process in website/README.md or CONTRIBUTING.md

Create schema validation for configs/ JSON files with schema documentation

The repo includes 3 config files (noi.conf.json, noi.space.json, noi_awesome.json) but there's no documentation of their expected structure, no JSON schema file, and no validation. This makes it difficult for users to extend or contributors to maintain these configs correctly.

  • [ ] Create configs/schema/ directory with JSON Schema files for each config (e.g., noi.conf.schema.json)
  • [ ] Add validation script in configs/validate.js to check all .json files against their schemas on build
  • [ ] Document the schema and allowed properties in configs/README.md with examples
  • [ ] Integrate validation into CI pipeline (.github/workflows/deploy.yml) to prevent invalid configs from being merged

Good first issues

  • Add missing translations: The locales/ directory has 20+ languages but some may be incomplete. Audit locales/{lang}/app.json files against locales/en/app.json to identify missing keys and submit translations for underserved languages (e.g., expand Hindi/Urdu/Swahili coverage).
  • Document the extension system: extensions/README.md exists but is likely minimal. Write comprehensive documentation on how to create, load, and distribute Noi extensions with a worked example.
  • Add integration tests for config loading: No visible test directory in file list. Create tests for configs/noi.conf.json and configs/noi.space.json parsing and validation to ensure config changes don't break the app.

Top contributors

  • @lencx β€” 81 commits
  • @gh0stkey β€” 4 commits
  • @ferivoq β€” 3 commits
  • [@Shixian Sheng](https://github.com/Shixian Sheng) β€” 2 commits
  • @unknwon β€” 1 commits

Recent commits

  • 48f641e β€” Merge pull request #438 from unknwon/patch-1 (lencx)
  • da242b5 β€” Update download link to version 1.1.0 (unknwon)
  • 08f714c β€” Merge pull request #436 from sony-level/add-grokipedia-shortcut (lencx)
  • 8bc0d7d β€” feat(config): add Grokipedia to AI services (sony-level)
  • 4d2766d β€” chore: conf (lencx)
  • fd49324 β€” release v1.1.0 (lencx)
  • 7590dcd β€” chore: conf (lencx)
  • f7f2b76 β€” release v1.0.0 (lencx)
  • 7d9203f β€” v1.0.0 (lencx)
  • 83d7f6e β€” fix: deepseek send (lencx)

Security observations

The Noi website project maintains a reasonably secure posture with modern dependencies (React 18, TypeScript 5.2, Docusaurus 3.0). The primary concerns are around dependency management practices (inconsistent version constraints), lack of visible security configuration in Docusaurus, and missing security documentation. No critical vulnerabilities detected in the provided dependency list. The project follows standard practices for a documentation website built with Docusaurus. Recommended actions include standardizing dependency version constraints, establishing a dependency update strategy, and adding security-related configuration and documentation.

  • Medium Β· Outdated Docusaurus Dependencies β€” website/package.json - @docusaurus/core, @docusaurus/preset-classic, @docusaurus/module-type-aliases, @docusaurus/tsconfig, @docusaurus/types. The project uses Docusaurus 3.0.1 which was released in 2023. While not critically outdated, it should be regularly updated to receive security patches and bug fixes. No patch version updates are applied (3.0.1 is pinned without caret/tilde). Fix: Regularly update dependencies using npm audit and npm update. Consider adopting a dependency management strategy (e.g., Dependabot) to automatically check for security updates.
  • Medium Β· Mixed Dependency Version Constraints β€” website/package.json - dependencies and devDependencies. The project uses inconsistent versioning strategies - some dependencies are pinned (e.g., @docusaurus packages at 3.0.1), while others use caret ranges (^). This can lead to unexpected minor/patch version changes and potential compatibility issues. Fix: Standardize version constraints. Use either exact pinning for all production dependencies or consistent caret/tilde ranges. Consider using npm ci instead of npm install for reproducible builds.
  • Low Β· TypeScript Version Constraint β€” website/package.json - typescript devDependency. TypeScript is pinned to ~5.2.2 with a tilde constraint, which allows patch updates but not minor versions. This can lead to inconsistencies in type checking across different environments. Fix: Either pin TypeScript to an exact version (e.g., 5.2.2) or allow minor updates with an explicit policy. Ensure all team members use the same version by leveraging .node-version or .nvmrc files.
  • Low Β· Missing Security Headers Configuration β€” website/docusaurus.config.ts (not provided). The docusaurus configuration file (website/docusaurus.config.ts) is not visible in the provided structure. Security headers like CSP, X-Frame-Options, and X-Content-Type-Options should be configured for the website. Fix: Configure security headers in docusaurus.config.ts. Add meta tags for Content Security Policy, ensure X-Frame-Options is set to prevent clickjacking, and configure other security-related headers.
  • Low Β· No Package Lock File Visible β€” website/ directory root. The analysis does not show package-lock.json or yarn.lock in the file structure. This could indicate missing or untracked lock files, which can lead to non-deterministic builds and supply chain risks. Fix: Ensure package-lock.json (npm) or yarn.lock (yarn) is committed to version control. This guarantees reproducible builds and prevents unexpected dependency version changes.
  • Low Β· Configuration Files in Repository Root β€” configs/ directory. Configuration files (noi.conf.json, noi.space.json) are stored in the repository. If these contain sensitive information, they could be exposed. Fix: Review configuration files for sensitive data. Use environment variables for secrets. If configuration contains examples only, document this clearly and ensure actual secrets use .env files with .gitignore rules.
  • Low Β· Missing CODEOWNERS and Security Policy β€” Repository root. No visible SECURITY.md or CODEOWNERS file found. This could make it harder for security researchers to report vulnerabilities responsibly. Fix: Create SECURITY.md with instructions for responsible disclosure. Add CODEOWNERS file to clarify maintainers responsible for security decisions.

LLM-derived; treat as a starting point, not a security audit.

Where to read next


Generated by RepoPilot. Verdict based on maintenance signals β€” see the live page for receipts. Re-run on a new commit to refresh.

Mixed signals Β· lencx/Noi β€” RepoPilot