Nosis MCP Server

<div align="center"> <img src="docs/nosis-banner.png" alt="Nosis" width="560"> <br><br> <b>English</b> &middot; <a href="README.zh-CN.md">简体中文</a> </div>

Nosis is an open-source, lightweight personal agent application. It provides local workspace operations, human approval, session persistence, context management, long-term memory, plans, subagents, scheduled tasks, and Skill / Plugin / MCP extensibility — with a TUI, a GUI, and Feishu messaging access.

TUI ───────────────────────── Bridge ── agent_runtime ── agent_core
nosis-server
├─ HTTP / WebSocket (optional) ── GUI
├─ IM (Feishu)
└─ Session Host ── Bridge ── agent_runtime ── agent_core

• agent_core provides frontend-agnostic agent mechanisms.
• agent_runtime reads application configuration and assembles the Core into a runnable instance.
• Bridge runs as a standalone process and is the only channel through which a frontend drives the Runtime.
• The TUI, GUI, and messaging hosts share execution state and interaction semantics through the Bridge protocol; the Bridge subprocess channel uses newline-delimited JSON.

Key capabilities

• Controlled local execution: A session supports three permission presets — Ask for approval, Workspace Access, and Full Access. Shell enters the workspace sandbox or the host environment according to scope, while file tools are always confined to the current workspace.
• Desktop automation: The main agent can observe and operate the visible desktop through computer_screenshot and computer_action, covering screenshots, clicks, drags, scrolling, key presses, and text input. Both tools are on by default and visible only to the main agent, and each call is confirmed according to the current permission preset. Actions return a screenshot by default and can skip it with screenshot: false. On Windows the tools also support visible-window crops and window-relative input. Pass the latest screenshot path as observation and use its hwnd:<decimal> for a window-scoped action.
• Web research: web_fetch reads public pages directly or via DeepSeek; web_search, when enabled, queries DuckDuckGo by default and can switch to Exa or DeepSeek.
• A complete agent loop: streaming responses, tool batches, context compaction, steer, cancel, plans, and background jobs.
• Resumable sessions: conversation and execution events are written to an append-only JSONL journal, and the TUI and GUI can read the same kind of session.
• Memory and scheduled tasks: global and workspace-scoped long-term memory, plus one-shot, interval, and cron tasks.
• Models and media: OpenAI-compatible endpoints use the native OpenAI SDK; other routes and image generation use LiteLLM. Providers can be routed independently for the main agent, vision, image generation, auxiliary model calls, and each subagent role.
• Extension system: standalone skills, skills / agents / MCP / command hooks provided by plugins, and standalone MCP servers.
• Multiple frontends: the TUI suits terminal workflows; the GUI offers multi-session management, attachments, a file tree, settings, memory, and scheduled tasks; Feishu supports workspace and session selection, streaming text, questions, and approval cards.

Quick start

Requirements: Python >= 3.11, Node.js >= 22, and uv.

git clone https://github.com/EvannZhongg/Nosis.git
cd Nosis
npm install
npm run build
uv tool install --editable ".[server]"

To enable HTTP / WebSocket access in the project environment, install the server extra:

uv sync --extra server

Start the TUI once in the current directory:

nosis

The first launch initializes ~/.nosis/. After quitting the TUI, create ~/.nosis/.env and fill in the environment variables required by the default provider, for example:

OPENAI_KEY=your-api-key

Then restart the TUI:

nosis

Or start the shared GUI / IM server:

nosis-server

The GUI listens on http://127.0.0.1:8737 by default.

Feishu messaging access is configured in ~/.nosis/im_channels.json; see Mobile / IM setup. nosis-server runs HTTP and IM adapters alongside a shared Session Host and Bridge. Use nosis-server --no-http to run without HTTP dependencies or a local listening port. A configuration-directory process lock prevents duplicate servers; a second launch reports that the server is already running.

Module documentation

Third-party frontends can launch the installed nosis-bridge command and use the public stdio protocol or the lightweight @nosis/client TypeScript SDK.

Public contracts:

Document	Scope
docs/bridge-protocol	Stdio transport, commands, events, runtime phases, transcript checkpoints, and error rules for third-party clients
docs/bridge-api-design	Which messages are public or internal, who owns them, and the versioning decisions
docs/plugin-hooks	Command hook declarations, checkpoints, invocation payloads, and decisions
docs/plugin-interop	Assembly, static validation, error isolation, and re-assembly of plugin components

Runtime layers:

Document	Scope
agent_core	Agent loop, context, session, tools, execution, permissions, memory, plans, jobs, scheduler, providers, skills, and MCP mechanisms
agent_runtime	Configuration, prompts, plugin discovery, runtime assembly, execution plane, session binding, and turn entry

Frontends and SDK:

Document	Scope
interfaces	Shared host modules, launch entries, Bridge process and channel attachment, and the allowed Core reuse boundary
interfaces/bridge	The standalone Bridge process, protocol routing, event translation, and frontend interaction forwarding
interfaces/protocol	The TypeScript protocol package: exports, build, and change checklist
interfaces/client	Public Node/TypeScript stdio client, process lifecycle and integration example
interfaces/tui	The Ink terminal interface, commands, input state, and Bridge subprocess attachment
interfaces/gui	The FastAPI service, React interface, multi-session connections, HTTP / WebSocket API, and media access
interfaces/mobile	Feishu transport, workspace and session selection, streaming text, questions, approvals, and shared-host setup

Configuration and data

agent_runtime creates the configuration directory on first launch and is responsible for reading and updating the application configuration inside it:

Path	Contents
~/.nosis/provider_config.json	Providers, models, and role routing, including the optional fast_model
~/.nosis/agent_config.json	Tools, context, memory, skill paths, subagents, MCP, workspace instructions, and scratch workspace settings
~/.nosis/im_channels.json	Messaging channels, credentials, and authorized Feishu users
~/.nosis/tool_config.json	Web Search and Web Fetch provider selection and API keys
~/.nosis/.env	The secrets and environment variables referenced by the configuration
~/.nosis/prompts/	Main agent, subagent, compaction, and memory prompts
~/.nosis/skills/	Standalone skills
~/.nosis/plugins/	Plugin capability packages
~/.nosis/AGENTS.md	User-level global workspace instruction
~/.nosis/MEMORY.md	Global long-term memory
~/.nosis/sessions/	Session journals, workspace memory, artifacts, subagent records, and per-session auxiliary usage logs
~/.nosis/schedule.jsonl	Scheduled tasks and run records
<workspace>/.nosis/attachments/	Uploaded attachments and agent-generated images

The default configuration and built-in resources live in agent_runtime/defaults/. See agent_runtime/README.md for how assembly works.

Development and testing

Python tests use a mock provider and need no real API key:

python -m venv .venv
source .venv/bin/activate
python -m pip install -e ".[gui,test]"
python -m pytest --durations=20

On Windows, activate the environment with .venv\Scripts\Activate.ps1.

Pytest distributes test classes across four isolated worker processes. Use -n 0 for a serial run or -n 2 on smaller machines. The full suite includes package installation and real local MCP/sandbox processes; --ignore=tests/test_bridge_client.py omits the package installation check during iteration. The standalone plugin testkit has its own command in docs/plugin-interop.md.

The server extra includes FastAPI, Uvicorn, the WebSocket backend, and multipart support; Windows, macOS, and Linux use the same installation. The TUI and nosis-server --no-http do not require this extra.

Frontend build, type checking, and tests:

npm run build
npm run typecheck
npm test

The Linux sandbox integration tests require a working bubblewrap and user namespaces; when the runtime conditions are not met, the tests explicitly skip.

On Windows the shell tool uses PowerShell 7, so PowerShell 7 has to be installed separately.

Contributors

• AKArrok: reported and verified the append-only journal tail-append issue (#2).
• George Pickett: contributed the Parallel Search MCP integration (#4).
• Pocket99: contributed the initial GUI, with sessions, workspace browsing, and model switching (#1).
• Guillermo Prieto Rodriguez: reported the file-tool path race that let a sandboxed shell redirect workspace reads and writes outside the workspace.

License

MIT