# Inline: a thread-first chat app with Rust clients, a Bun server and a CLI for agents > Inline is a chat application built for multiplayer work with teams, AI agents and friends, with a macOS and iOS client in beta, a Rust core and CLI, and integrations for MCP, plugins and agent bridges. The core is AGPL-3.0 while the SDK, CLI and plugins are Apache-2.0, and only the Apple platforms are available today. **inline-chat/inline** — Inline is the chat app you always wanted. Fast, native, lightweight, open, secure and the delightful interface for working with agents, teammates and friends. - Repository: https://github.com/inline-chat/inline - Website: https://inline.chat - Stars: 902 · Forks: 42 - Language: TypeScript - License: AGPL-3.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/inline-chat-inline ## Chat designed thread first, and positioned against Slack Inline is described as a chat app that replaces Slack, Discord, Telegram and similar tools for working with your team, agents and friends. The README is careful about the scope: it is general-purpose, but designed thread first to enable the best interface for all multiplayer work. That thread-first framing is the product decision, and it is what separates this from another channel-based messenger. A channel is a permanent room that everything lands in. A thread is a bounded conversation that can be started, shared by link, and read later without the noise of a busy room in the way. The README's own get-started list points at exactly that use, with a skill for your coding agent to add Inline as a channel next to Slack, Telegram, Discord or Teams. The interesting part for an engineering team is that agents are treated as first-class participants rather than as a bolt-on. The README lists separate entry points for agents, for the CLI, for MCP, for plugins, and for adding Inline to a product or bot, alongside a ChatGPT plugin link. The supported agent list names OpenClaw, Hermes Agent, Codex, Claude and OpenCode. That combination is what makes the project worth examining even though it is young. A chat app where a human and a coding agent share a thread is a different artefact from a chat app with a bot bolted on, and the repository backs the claim up with an agent-bridge crate, two agent driver crates, an MCP package and a set of plugins in the tree. What the README does not yet contain is the design rationale. A long section of the document describing the goals for the product sits inside an HTML comment, which means it is drafted but not published. The public documentation is therefore thin on why threads beat channels, and the argument has to be reconstructed from the one published sentence about being thread first. ## Only the Apple platforms exist today The platform table in the README is the most decisive fact about this project, and it is worth reading literally. macOS is Beta. iOS is Beta. Web is Planned. Android is Not started. Windows is Not started. Linux is Not started. The download link in the get-started section says the same thing in prose: Inline is available in beta for macOS and iOS. So a team evaluating this has to accept that the application itself, the part people use, exists on two operating systems from one vendor. If your organisation is mixed-platform, the answer today is that the non-Apple half of the team cannot use the client, whatever the roadmap says. The README does not publish dates for the planned web client or for the platforms that have not started, so there is no schedule to plan against. There is a second, subtler limitation in the same area. The Apple client is native, which is visible in the repository rather than in the README: the tree has an apple/ directory, a .swift-version file, a Cargo.toml, and package.json scripts that invoke Swift linting and Apple source contract checks. A native macOS client means a Swift codebase, which means the desktop app and the server are different languages in different build systems, and it means the web client, when it arrives, is a third implementation of the same protocol. The protocol is defined once, though, in a proto/ directory, and the package.json has a generate:proto script and a public:sync script that runs a Rust proto sync, so the cross-language story is handled by generated code rather than by hand-written clients. For a personal or Apple-only team, none of this is a problem. For an organisation deciding on a chat platform for a hundred people, it is the whole decision. ## A Rust CLI and core crates, a Bun server, and Effect on the JavaScript side The repository is a polyglot one, and the layout tells you how the pieces fit. The Cargo.toml at the root defines a Rust workspace whose members are cli, crates/agent-bridge, crates/agent-driver-acp, crates/agent-driver-codex, crates/client, crates/protocol and crates/sdk. It excludes a vendored copy of the agent client protocol. The workspace package metadata sets version 0.7.17, edition 2024, a minimum rust-version of 1.96, and an Apache-2.0 licence, with the repository and homepage pointing at the project. Release profiles are configured too, with fat LTO, stripped symbols and a single codegen unit for release builds. The dependency list shows what the server and client actually need: axum for the HTTP and websocket layer, tokio for the async runtime, prost and prost-build for protocol buffer handling, reqwest with rustls-tls for outbound calls, rusqlite with the bundled feature for the database, tower, serde, uuid and tokio-tungstenite for websockets. The JavaScript side is a Bun workspace. The package.json names bun@1.4.0 as the package manager and lists workspaces for server, cli, landing, packages/bot-client, packages/bot-api-types, packages/mcp, packages/oauth-core, packages/protocol, packages/sdk, the server packages, scripts, plugins/openclaw, plugins/hermes-agent, plugins/chat-sdk-plugin, plugins/chatgpt/ui and the landing packages. The dependency catalog pins Effect and its platform and vitest packages at 4.0.0-beta.98, with oxlint, TypeScript 7.0.2 and vitest 4.1.10 alongside. Two observations. First, the server is JavaScript on Bun with Effect, while the CLI and SDK are Rust, so the project carries two server-side runtimes and a protocol layer between them. Second, several pinned dependencies are betas, which for a project whose client is also in beta is coherent, but it does mean the dependency surface is moving. The scripts show the working vocabulary. There is dev, which runs the server in development, dev:landing for the marketing site, and db:migrate, db:generate and a db:dangerously-reset-db for the database. There are platform-specific helpers for the iOS and macOS debug apps, a matrix-inline:e2e script for end-to-end runs, and lint:apple and check:apple for the Swift side. ## The CLI, the MCP server and the agent bridge as integration points The get-started section is where the project's real architecture shows through, because it is a list of integrations rather than a list of features. There is a Download link for the beta clients, a link to install the CLI, and a link to add your agents. The agent page, in the README's words, covers setting up OpenClaw, Hermes Agent, or Codex, Claude, OpenCode and so on to use them from Inline. There is a link for adding Inline to your product or bot, described as a skill for your coding agent to add Inline as a channel next to Slack, Telegram, Discord or Teams, and a link for MCP and plugins to connect Inline to your favourite LLM to catch up, send messages and use threads for context. The phrase to sit with is that last one. Using threads for context means the conversation history a model is given comes from a structured thread rather than from a flat message log, which is exactly the kind of thing an agent integration needs and which a generic webhook does not provide. The repository backs it: packages/mcp is a workspace package, crates/agent-bridge is a crate, and there are agent driver crates for ACP and for Codex specifically, with the agent client protocol vendored under vendor/. The CLI is the other half of the story, and it is the piece that makes Inline usable in a script or a coding session rather than only in a window. The README describes it as a way to create workflows and interact with Inline with all the features of the clients. The cli-v0.7.17 release tag from 2026-10-13 matches the version in the Rust workspace, so the CLI ships on its own cadence separate from the app. The practical value of this set of entry points is that a team can start with the CLI and the MCP server, wire an agent into a thread, and only then decide whether the native clients matter. That is a much lower commitment than adopting a chat platform wholesale. ## AGPL for the core, Apache-2.0 for everything you embed Inline uses two licences, and the boundary between them is drawn explicitly in the README's License section. The core is AGPL-3.0-only. The SDKs, the CLI, the plugins and related components are Apache-2.0. Third-party notices remain applicable, and the README points at a LICENSING.md file for the component boundaries, and that file exists at the root of the tree alongside LICENSE, LICENSE-APACHE and LICENSE-UNICODE. This split is the single most important licensing fact for an adopter, and it is unusually well handled. Under AGPL, a modification of the core that you offer to users over a network obliges you to make that modified version available. Under Apache-2.0, the SDK and CLI carry no such condition, so a commercial product can embed the client library and the command-line tool without open-sourcing its own code. The practical split is sensible: the server and the core are where the interesting modification happens, and the client-facing pieces are where adoption friction would be worst. The repository also carries a SECURITY.md and a SUPPORT.md, and the README links to a security documentation page and an APIs page, both under inline.chat/docs. For a chat product that holds a team's conversations, the existence of a documented security page and a support file is a reasonable baseline. One caveat is worth stating: the AGPL obligations for a modified core offered as a network service depend on facts this review cannot judge, such as how you deploy it and what counts as a modification. That is a question for your own counsel, and the answer will depend on the component boundaries described in LICENSING.md rather than on this summary. ## A young project, a beta client and no stability to lean on On maintenance, the repository is not archived and the last push was on 2026-10-20, on the main branch. The activity is high: the recent release tags are cli-v0.7.17 from 2026-10-13, a beta tag from 2026-09-26, and a tip tag from 2026-01-29. Reading the tag names tells you something about the release process. There is a channel for the CLI, which is versioned like a normal package, and separate moving tags named beta and tip, which are the kind of rolling tags a project uses for a client that is not yet versioned as a release. The tip tag dates from January 2026 and the beta tag from September 2026, so both are in use as moving references rather than fixed versions. The honest assessment is that this is a fast-moving project with a young client, and there is no stability story to lean on. The README calls the app a beta for macOS and iOS, the published design rationale is still commented out in the README, and the repository contains four platform rows that are not started. What balances that is the shape of the risk. The AGPL and Apache split means the parts you embed are permissively licensed, and the integration surface is documented at the level of a CLI, an MCP server and a set of plugins. A team that adopts the CLI and the SDK can build on a contract that is less likely to move under them than a chat UI, and the plugin and agent-bridge crates are the parts most likely to be adjusted as the agent protocols evolve. The tree also shows the discipline of a larger project: an AGENTS.md and a CONTRIBUTING.md for coding agents and contributors, a .agents/ directory and a .codex/ directory, a skills/ directory for the agent-facing skills, proto/ for the wire format, and vendor/ for a pinned copy of the agent client protocol. That is a codebase built to be extended by machines as much as by people. ## Conclusion Inline fits a team that wants a chat surface its coding agents can use as a channel, since the CLI, the MCP server, the agent bridge and the bot plugins are documented entry points rather than a future promise, and the split licence lets you embed the SDK and CLI in a closed product. It is the wrong choice if any of your users are on Windows, Linux, Android or the web, because those platforms are listed as not started or planned, and it is the wrong choice if you need a stable, long-lived deployment, because the app is in beta and its licence boundaries are still being written down in LICENSING.md. Before you depend on it, read LICENSING.md to see exactly which component you are picking up, and check the platform table before you plan a rollout. ## FAQ ### Which platforms does the Inline chat app support? The README's platform table lists macOS and iOS as Beta, Web as Planned, and Android, Windows and Linux as Not started. The download link says Inline is available in beta for macOS and iOS. ### How do I use coding agents with Inline? The README points to an agents page covering OpenClaw, Hermes Agent, Codex, Claude and OpenCode, and to MCP and plugins pages for connecting an LLM to catch up, send messages and use threads for context. The repository contains packages/mcp, crates/agent-bridge and agent driver crates for ACP and Codex. ### What licence applies to Inline? The core is AGPL-3.0-only, while the SDKs, CLI, plugins and related components are Apache-2.0. The README points at LICENSING.md for the component boundaries, and the tree also holds LICENSE, LICENSE-APACHE and LICENSE-UNICODE. ### Is there a command line tool for Inline? Yes. The README links to a page for installing the CLI, describing it as a way to create workflows and interact with Inline with all the features of the clients. The CLI is a Rust crate in the workspace and is versioned separately, with the cli-v0.7.17 tag released on 2026-10-13. ### What is Inline built with? The repository is a Bun workspace for the server, landing site, MCP package, SDK and plugins, and a Rust workspace for the CLI and crates including the agent bridge, client, protocol and SDK. The Rust workspace pins version 0.7.17, edition 2024 and rust-version 1.96, and uses axum, tokio, prost, reqwest with rustls-tls and rusqlite. ## Sources - [inline-chat/inline on GitHub](https://github.com/inline-chat/inline) - [License: AGPL-3.0](https://github.com/inline-chat/inline/blob/main/LICENSE) - [Project website](https://inline.chat) - [README](https://github.com/inline-chat/inline/blob/main/README.md) - [Releases](https://github.com/inline-chat/inline/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/inline-chat-inline