Open-source agentic work platform for organizations.
English | 简体中文
Give everyone in your organization a Codex-powered AI agent — deployed on your infrastructure, with the models you choose.
Live Demo · Agent Setup · Quick Start · How it works · Architecture · Build with LinkSense
Hero.mp4
Open-source, self-hosted WorkBuddy alternative for organizations.
Give every user a full agentic workspace to research, browse, run code, analyze data, work with files, and create documents and artifacts.
Deploy LinkSense on your own servers or private cloud. Use OpenAI, Anthropic, Gemini, DeepSeek, Qwen, or your own local LLM.
Users, groups, Knowledge, Skills, Plugins, MCP, Applications, governance, and more are part of the open-source platform — not locked behind an enterprise edition.
Centrally manage access, models, knowledge, credentials, and capabilities. What works for one person can be shared, governed, and reused across teams.
Give Codex, Claude Code, Cursor, Windsurf, or another coding agent this prompt:
Help me install and start LinkSense by following https://raw.githubusercontent.com/LingX-AI/linksense/main/Install.md
The agent installation guide defaults to the released Core images, checks the host and both network channels, preserves existing installations, and reports the actual launch result. Add “for local source development” to the prompt if you want a cloned development workspace instead. Model credentials are configured in the administration UI after startup; the agent does not need to read your secrets.
Two deployment profiles ship from the same repository:
Core — AI workspace + organizational capability platform Full — Core + complete document processing and Knowledge retrieval
Use this table as a practical starting point. The recommended column leaves room for builds, browser tools, document processing, and other services on the host; it is a planning suggestion, not a measured user-capacity guarantee.
| Deployment target | Starting point | Recommended | Notes |
|---|---|---|---|
| Core evaluation | 4+ vCPU, 8+ GiB memory, 60+ GiB free SSD | 8 vCPU, 16 GiB, 100 GiB free SSD | A fresh installation defaults to one concurrent conversation. |
| Core shared server | 8 vCPU, 16 GiB memory, 120 GiB free SSD | 16 vCPU, 32 GiB, 200 GiB free SSD | Each active user Worker has a default 4 GiB memory limit; size concurrency separately. |
| Full (new installation) | 8+ vCPU, 10+ GiB memory, 120+ GiB free SSD | 16 vCPU, 32 GiB, 200 GiB free SSD | The minimum permits memory overcommit; OCR, large documents and concurrent tasks need extra headroom. |
Docker source development / pnpm dev |
8 vCPU, 24 GiB memory, 120 GiB free SSD | 16 vCPU, 32 GiB, 200 GiB free SSD | Builds and runs the development stack, including Knowledge services and task Workers. |
These numbers cover LinkSense with externally hosted model APIs. Size a local LLM and its GPU separately. Prefer Linux with Docker for a persistent shared server; macOS with Docker Desktop is suitable for evaluation and development when its VM has enough resources. A 16 GiB Mac should start with Core.
The memory check reads the memory actually available to Docker Engine. With Docker Desktop, this is the VM allocation, rather than the host's total RAM. An 8 GB allocation can report less than 8 GiB of usable memory. Adjust Settings → Resources → Advanced → Memory limit, then apply the changes and restart Docker Desktop; allocate at least 10–12 GB for Core and leave room above Full's 10 GiB usable-memory minimum. Full warns when combined service limits exceed available memory and continues without reducing those limits; this is not a peak-memory guarantee. Existing installations retain their resource settings during repair and upgrade. Plan capacity for workload peaks separately. See Deployment reference for the full list. See Installer host adaptation for automatic tool setup, resource profiles, CPU compatibility mode, proxies, and safe recovery.
Before installing Full in an x86_64 VM, confirm that the guest CPU supports
x86-64-v2. Host support alone does not mean those features are exposed to the guest. See Virtual machine CPU requirements for checks and CPU settings.
No source checkout, host Node.js, or pnpm is needed. The installer starts the application after checking the host; Docker must already be installed and running.
# Core
curl --http1.1 --retry 3 --retry-delay 2 --connect-timeout 15 --max-time 300 -fsSL \
-o install-core.sh https://raw.githubusercontent.com/LingX-AI/linksense/main/install-core.sh && sudo --preserve-env=http_proxy,https_proxy,HTTP_PROXY,HTTPS_PROXY,ALL_PROXY,all_proxy,NO_PROXY,no_proxy sh install-core.sh
# Full
curl --http1.1 --retry 3 --retry-delay 2 --connect-timeout 15 --max-time 300 -fsSL \
-o install-full.sh https://raw.githubusercontent.com/LingX-AI/linksense/main/install-full.sh && sudo --preserve-env=http_proxy,https_proxy,HTTP_PROXY,HTTPS_PROXY,ALL_PROXY,all_proxy,NO_PROXY,no_proxy sh install-full.shOpen the address printed by the installer (default: http://<server-address>:18081).
The Linux commands preserve only proxy environment variables through sudo, so
the bootstrap uses the same terminal proxy as curl. If sudo policy denies this,
ask the host administrator to configure the elevated environment's proxy.
# Core: execute only after the download succeeds; do not use sudo
curl --http1.1 --retry 3 --retry-delay 2 --connect-timeout 15 --max-time 300 -fsSL \
-o install-core.sh https://raw.githubusercontent.com/LingX-AI/linksense/main/install-core.sh && sh install-core.sh
# Full
curl --http1.1 --retry 3 --retry-delay 2 --connect-timeout 15 --max-time 300 -fsSL \
-o install-full.sh https://raw.githubusercontent.com/LingX-AI/linksense/main/install-full.sh && sh install-full.shOpen the address printed by the installer (default: http://localhost:18081).
Configure terminal downloads and Docker image pulls separately. See the network and proxy guide for Docker PATH discovery, HTTP/SOCKS5 ports, mirrors and network diagnostics.
To inspect the script first, run only the download part of the matching command
above, open the file with less install-core.sh (or less install-full.sh), then
execute it using the command for your OS.
The installer validates the host before writing persistent state and generates runtime secrets automatically. Initialization steps are listed below.
Linux stores deployment files under /opt/linksense; macOS uses ~/.linksense.
A domain and HTTPS are optional for local startup. Public deployments should place an
HTTPS reverse proxy in front of port 18081.
For code changes, follow Local Development for prerequisites, startup commands, and development ports. For image builds, see Building from Source with Docker.
- Open the printed address and use the initialization credential to create the first administrator. Store the credential privately.
- Configure a model provider in administration, then verify both a short chat and a task that uses tools. A healthy deployment does not prove model compatibility.
- Use Command-line management for a release installation, or Local Development for source watching and development lifecycle commands.
Open a Discussion and tell us what you are trying to do — we read
all of them. If you are evaluating LinkSense for an organization, we are working with a
small number of early design partners and will help you deploy: hello@linksense.org.
LinkSense gives every user their own AI workspace — and provides the organizational layer for turning what individuals build into capabilities that can be shared, governed, and reused across teams.
| Capability object | Organizational role |
|---|---|
| Knowledge Bases | Make organizational context available to AI with controlled access |
| Skills | Turn effective ways of working into reusable capabilities |
| MCP Servers | Connect AI to organizational systems and actions |
| Plugins | Package Skills and MCP integrations for reviewed distribution |
These capabilities can start with an individual and become reusable across the organization.
Skills and Plugins can move from personal development to immutable releases, administrative review, organizational publishing, installation, and explicit updates.
Knowledge Bases can be authorized to selected users and groups. MCP connections and credentials remain separately managed, allowing AI capabilities to connect to organizational systems without distributing underlying credentials to every user.
Delegated execution, not credential sharing.
Applications are where these capabilities come together.
An Application combines maintained instructions and model configuration with organizational Knowledge, Skills, Plugins, and MCP connections, then makes that experience available to authorized users and groups.
For example:
Users don't need to reconstruct the underlying setup themselves. They open an authorized Application and start their own Task with the maintained capabilities already composed for that use case.
Applications are not autonomous agents. They are reusable AI work entry points. Each authorized user starts and owns their own Task, while the Application provides the maintained configuration and organizational capabilities behind the experience.
Applications can also provide controlled access to creator-maintained Knowledge and MCP capabilities without giving users direct management access or exposing underlying credentials through normal LinkSense interfaces.
LinkSense adds identity, ownership, user/group authorization, publishing and review, credential management, model management, usage, audit, and runtime operations around these capabilities.
Together, they form the open capability layer between frontier AI and the organization.
LinkSense runs the open-source Codex runtime inside its own managed Workers. It does not depend on the Codex web application or a LinkSense-hosted Codex service.
LinkSense directly runs the official @openai/codex package through:
codex app-server --stdioand communicates with it through the Codex app-server JSON-RPC protocol.
The Codex runtime executes inside the LinkSense deployment. Model inference is configured separately: organizations can connect the model providers or compatible private endpoints they choose.
LinkSense does not fork Codex, patch its source, or reimplement the agent loop.
| Codex | LinkSense |
|---|---|
| Agent reasoning and Turns | Organizational workspace |
| Native tools and execution | Identity, sharing, and governance |
| Skills and Plugins | Publishing and organizational lifecycle |
| Models and sub-agents | Applications, Knowledge, and MCP management |
| Sandbox semantics | Workers, persistence, usage, and operations |
Codex decides how the agent executes. LinkSense decides what it can access, where it runs, how capabilities are shared and governed, and how execution is persisted and operated.
The Codex runtime is licensed by OpenAI under Apache-2.0 and ships unmodified; its
NOTICE file travels with our images. See
THIRD-PARTY-NOTICES.md.
Codex is a trademark of OpenAI. LinkSense is an independent project and is not affiliated with, sponsored by, or endorsed by OpenAI.
Run the complete platform on your own servers, private cloud, or VPC. Inspect the source, modify the platform, choose your models and integrations, and operate the environment on infrastructure you control. There is no required closed enterprise runtime, LinkSense-operated cloud control plane, or online license activation heartbeat.
With private models, local Knowledge, and local MCP services, prompts, files, Task state, Knowledge indexes, credentials, audit records, and results can remain inside infrastructure you control.
Configured external services may still make external network calls, so LinkSense describes itself as self-hosted and private-network friendly, not formally air-gapped.
Models: OpenAI · Azure OpenAI · Anthropic · Google / Vertex · Alibaba · DeepSeek · OpenRouter · OpenAI-compatible endpoints
For internal deployment exceptions, attribution requirements, and branding permissions, see License.
LinkSense dynamically manages one Docker Worker per active user.
Multiple Tasks belonging to the same user may reuse that Worker and share the user's
HOME and HOME/.codex (CODEX_HOME). Tasks without a project share workspace;
Tasks in the same project share projects/<projectId>. Task control data is stored
separately for each Task.
The isolation boundary is the user's Worker, rather than individual Task directories. Ordinary execution Tasks can access the same user's other project and Task files.
Inactive Workers are reclaimed. Per-user package environments can persist across reclamation, while generated artifacts persist independently in object storage.
Worker controls include configurable CPU/memory/PID limits, read-only root filesystems,
no-new-privileges, dropped Linux capabilities, non-privileged containers, non-root Task
processes, and separate control and egress networks.
Workers do not directly join PostgreSQL or Redis service networks. Internet egress is currently allowed; LinkSense does not enforce a universal domain allowlist or deny-all egress policy.
Ordinary execution uses Codex's approvalPolicy: never and full-access sandbox policy,
without per-command approval. If prompt injection in a webpage, uploaded file or tool
response successfully induces command execution, it can lead to reading, modifying or
exfiltrating that user's shared files. Plan mode uses a read-only sandbox with network
access disabled; it does not change ordinary execution permissions.
The application does not block cloud metadata addresses by default. Cloud deployments should restrict metadata access and outbound traffic through network or instance configuration, and grant instance roles only the permissions they need. The controller also holds the Docker socket and must be treated as a trusted management component; Task Workers do not mount that socket. See Execution boundaries.
Real-time Tasks normally follow:
They do not normally enter BullMQ before execution.
BullMQ primarily handles Automations, scheduled/background jobs, worker maintenance, recovery, email, billing, Knowledge synchronization and processing, and cleanup.
LinkSense provides three primary extension paths without requiring changes to LinkSense source.
Teach AI reusable methods, workflows, domain practices, scripts, references, and supporting resources using the native Codex Skill format.
Skills can be discovered natively by Codex or explicitly selected by users and Applications.
Connect external systems and APIs through MCP, then package MCP declarations together with Skills and supporting resources.
For CRM, ERP, SaaS, monitoring systems, and internal APIs, MCP is generally the recommended integration boundary.
Credentials remain separate from Plugin packages.
Build purpose-specific interfaces and workflows on top of authorized LinkSense capabilities.
Interactive Applications are packaged with manifest.json, HTML, JavaScript, CSS, and
assets, and run inside sandboxed iframes.
Their SDK can request explicitly permitted capabilities such as user profile access, capability discovery, Knowledge Base access, MCP Server discovery, and Task creation.
Interactive Applications are separate from normal Applications, which are primarily configuration and capability-composition objects.
For CPU, memory, and disk sizing by deployment scenario, see Deployment Sizing.
- Linux: x86_64 or ARM64 with the required Docker/kernel capabilities, including Ubuntu, Debian, Deepin, Fedora, RHEL, Rocky Linux, AlmaLinux, and CentOS
- macOS: Intel or Apple Silicon with Docker Desktop
- Release images support
linux/amd64andlinux/arm64 - Docker Engine API v1.45+
- Docker Compose v2.24.4+
curl- TCP port
18081available by default
Full's RAG Knowledge Base components (Elasticsearch and Docling) require the Docker Engine host or VM to expose at least x86-64-v2 CPU features on x86_64 / amd64. The current Docling v1.36.0 upstream image uses CentOS Stream 9, which has an x86-64-v2 baseline. Elasticsearch's CPU requirements depend on its version and base image. This x86 instruction-set requirement does not apply to native ARM64 deployments.
Generic virtual CPU modes can mask features supported by the physical host. CPU model, age, vCPU count, and uname -m alone do not establish compatibility. Run these checks inside the Linux VM that actually runs Docker Engine:
LC_ALL=C lscpu
grep -m1 '^flags' /proc/cpuinfoIn addition to the x86-64 baseline, CPU flags must include cx16, lahf_lm, popcnt, ssse3, sse4_1, sse4_2, and SSE3 (usually shown as pni on Linux, or sse3). Checking only sse4_1 and popcnt does not establish full x86-64-v2 support.
Release install, repair, and upgrade scripts automatically check the CPU flags visible to Docker for Full on linux/amd64. They report missing features and exit before changing runtime configuration, creating data volumes, or stopping existing services. The check uses the release manifest's digest-pinned BusyBox image, which may need to be pulled on first use. Its temporary container is read-only, has no network or data-volume mounts, and is automatically removed on exit.
This preflight ships with releases that include this change; scripts in older installation directories are not updated automatically. To get the check before the first upgrade, use the online upgrade.sh command below after the updated release is published.
If required features are missing, or container logs report Fatal glibc error: CPU does not support x86-64-v2:
- Shut down the VM cleanly and change its CPU mode in the virtualization platform. In Proxmox VE, select
hostorx86-64-v2-AESif supported by the physical host. With KVM/libvirt, usehost-passthrough. Avoidkvm64/qemu64modes that mask required features. - Power the VM back on and check the flags again inside the guest. Restarting containers alone does not apply virtual CPU changes. For migration between hosts, choose a CPU model supported by every destination host that also meets
x86-64-v2. - Once the checks pass, rerun the original Full install command for a new installation; for an existing installation, follow Repair and upgrade, then check services using Command-line management.
If the physical CPU lacks the required features, use a compatible host. Adding vCPUs or memory cannot supply missing instructions.
After downloading the selected installer using Quick Start, pass the port when executing it. For Full:
# Linux
sudo --preserve-env=http_proxy,https_proxy,HTTP_PROXY,HTTPS_PROXY,ALL_PROXY,all_proxy,NO_PROXY,no_proxy env LINKSENSE_HTTP_PORT=19090 sh install-full.sh
# macOS
env LINKSENSE_HTTP_PORT=19090 sh install-full.sh| Action | Command |
|---|---|
| Check service status | linksense status |
| Start / stop / restart | linksense start / linksense stop / linksense restart |
| Show the access address | linksense address |
| Change the HTTP port | linksense port 19090 |
| Show the initialization credential | linksense credential |
| View service logs | linksense logs api / linksense logs runner |
| Check deployed service health | linksense doctor |
| Check downloads and image pulls | linksense doctor --network |
| Repair the installed release | linksense repair |
| Upgrade the installation | linksense upgrade |
Run linksense without arguments to open the interactive control menu.
Updated Linux management tools request sudo when needed and preserve only proxy
variables. On macOS, add $HOME/.local/bin to PATH and run
commands without sudo.
Network diagnostics require a release containing the updated installer and CLI. They pull BusyBox/API release images without starting containers; images remain cached.
Repair stays on the installed release. Upgrade detects Core/Full, waits for active work,
and stores a validated PostgreSQL backup under volume://linksense-backups/postgres/
before migration.
No data volume is deleted. A failure after migration begins does not trigger an automatic database rollback; retain the printed backup location and rerun the upgrade after reviewing diagnostics.
If the installed CLI is unavailable, download repair-core.sh or repair-full.sh, inspect it, and run it using the execution steps for your OS in Quick Start. For the first upgrade of an older installation, follow Installer host adaptation.
| Layer | Stack |
|---|---|
| Web | React 19 · TypeScript · Vite · React Router · TanStack Query · shadcn/ui · Base UI · Tailwind · i18next |
| API | Node.js · TypeScript · Fastify 5 · Zod · Prisma · PostgreSQL · Redis · BullMQ · MinIO |
| Runner | Node.js · TypeScript · Fastify · Docker · official Codex app-server · Chromium / Playwright |
| Knowledge | Docling · Elasticsearch · BM25 + vector retrieval · RRF · optional reranking |
Requires Node.js 24+, pnpm 10.34.6, Docker Engine/Compose, rsync, and mkcert for the local HTTPS certificate. The first launch may request system trust for mkcert's local certificate authority.
Applications and dependencies run in Linux containers; host rsync only synchronizes source files. Development defaults must not be used for public production deployments.
The API and development images include FFmpeg for voice transcription. Recordings
are normalized to 16 kHz mono PCM WAV before being sent to the configured service;
OpenAI-compatible services receive response_format=json without timestamps.
Host-based API development requires ffmpeg on PATH. After upgrading, deploy the
new API image; existing model settings and gateway credentials remain usable.
Run pnpm --filter @linksense/api test:voice:audio for native audio-format checks.
corepack enable
corepack prepare pnpm@10.34.6 --activate
pnpm install --frozen-lockfile
pnpm dev:prepare
pnpm devDefault addresses:
- Web:
http://localhost:18172 - Web HTTPS:
https://localhost:18173 - API:
http://localhost:4000 - Runner:
http://localhost:4010
Common commands:
pnpm dev:stop
pnpm dev:rebuild
pnpm dev:worker:rebuild
pnpm test
pnpm typecheck
pnpm lint
pnpm buildpnpm dev:prepare builds application images, the production Task Worker, and the bilingual
Help Center; checks infrastructure and database initialization; starts services; and warms
runtime caches.
pnpm dev prepares missing inputs automatically and attaches source watching and logs.
Before using Codex or another AI coding tool, read AGENTS.md.
AI-generated features and behavior changes require tests like any other contribution. Run affected tests, type checking, linting, and builds before committing.
Never commit secrets, personal data, internal requirement documents, or generated artifacts.
docker compose --env-file .env.example build \
migrate api runner runner-worker-image webMulti-platform build:
docker buildx build --platform linux/amd64,linux/arm64 --target runtime \
-f Dockerfile.api -t <registry>/linksense-api:<tag> --push .| File | Target | Output |
|---|---|---|
Dockerfile.api |
runtime / migration |
API / database migration |
Dockerfile.web |
runtime |
Web + Help Center |
Dockerfile.runner |
controller / worker |
Runner controller / Task Worker |
Production-like local stack:
pnpm dev:prod
pnpm dev:prod:stopFor production, prefer verified release images pinned to immutable digests rather than building source directly on the production host.
See SECURITY.md.
Security reports: security@linksense.org
See CONTRIBUTING.md and AGENTS.md.
Contributions require a Contributor License Agreement — CONTRIBUTING.md explains exactly why, and what we committed to in return.
If your organization runs LinkSense, we would like to know — add a row to
ADOPTERS.md. Listing is entirely optional, and we never add anyone who
did not ask. Would rather not be public? hello@linksense.org.
See SUPPORT.md.
LinkSense is open source under CPAL-1.0 — an OSI-approved license (Mozilla Public License 1.1 plus a small attribution notice and a network-use clause).
Run it internally, at any scale, modified or not — with no obligation to publish anything. Our Internal Deployment Exception puts that beyond doubt. Proprietary plugins and extensions written in your own files stay yours; CPAL's copyleft is per-file and does not reach your code.
Two obligations, and they trigger differently — this is the part people most often get backwards:
| Triggered by | Internal deployment | |
|---|---|---|
| Publish your changes | redistributing, or serving third parties | no |
| Show the attribution | launching through a graphical interface | yes |
The graphical attribution is a small notice — the words Powered by and our mark,
18–24px tall. The bundled interface links it to our site, but the license does not
require a URL. No copyright line or visible URL is required. It lives in a single
area at the foot of the interface and stays there as people move around, so no
screen needs its own copy. Here is exactly what it looks like.
Where it is not required, written into the licence rather than left to interpretation:
| Dialogs, menus, tooltips | not repeated — the screen underneath already carries it |
| Full-screen editing, preview, presentation | may be hidden, as long as it returns on exit |
| Documents, decks and images your people export | no watermark of any kind, ever |
| Command-line, headless, API-only | no display obligation at all |
Trademarks are licensed separately. Fork it, rename it, ship it, compete with us — just don't call it LinkSense. See TRADEMARK.md.
No rug-pulls. Every version released under CPAL-1.0 stays under CPAL-1.0, permanently. We will never retroactively tighten terms, and that promise is written down.
Deploy it under your own brand. Rename it, restyle it, put your own logo in the
header — no permission needed. The one-line notice is what stays. Need that gone too, or
need different terms? licensing@linksense.org.
Third-party components retain their own licenses; see THIRD-PARTY-NOTICES.md.