InnyTypes

InnyTypes is a desktop application that turns recordings and other sources into Anytype objects. You draw each automation as a flow on a canvas: a source starts it (a recorder or a watched folder), each step does one piece of work (transcribe, summarise, create an object), and questions stop the flow until you answer. The canvas and the engine underneath are an embedded Node-RED; every step comes from an installed package, never from npm.

It also serves the official Anytype MCP tools to AI apps on the same machine, so Claude, Codex and other assistants can read and write your Anytype through one loopback address and one token. The vocabulary and the design are in plan 0017 and plan 0018.

The current version is 0.2.1, a pre-release for macOS. It is not signed by Apple, so macOS warns on first open. To install it, follow docs/INSTALL.md; the downloads are on the v0.2.1 release.

Run from a checkout (developers)

The application lives in app/ and is built with npm workspaces from the repository root:

npm ci
npm run --workspace app build

There is no script that starts the development app on its own. The end-to-end harness (app/test/e2e/app-harness.ts) is the only runner: it builds the app and launches Electron on app/ with a temporary user data directory.

npm run --workspace app test:e2e

Related MCP server: macOS Companion MCP Server

Connect an AI client through MCP

While InnyTypes is running, it exposes its supervised Anytype tools to independent AI clients at:

http://127.0.0.1:31010/mcp

The application's Anytype panel shows the address this installation is actually configured with on its MCP endpoint row, with available or degraded beside it; that row is the one to copy from. Clients connect with MCP Streamable HTTP and a bearer token stored at ~/.config/innytypes/mcp_proxy_token; this proxy token is separate from the Anytype API key. InnyTypes and the AI client keep independent lifecycles—neither launches or stops the other.

The address is a stored setting, and a stored value is what InnyTypes serves. Put another port in the [mcp] section of ~/.config/innytypes/config.toml, then use it in every client URL; host selects another numeric loopback address, and InnyTypes refuses LAN, public, wildcard, and hostname binds. INNYTYPES_MCP_HOST and INNYTYPES_MCP_PORT are the default for a machine that has never been configured: they select the address only while nothing is stored, and are ignored once it is. Port 31009 is Anytype's REST API and is not an MCP endpoint.

See Connect an independent MCP client to InnyTypes for Codex configuration, generic MCP client setup, architecture patterns, security, and troubleshooting.

Command-line overview

innytypes addons install <name>==<version>  # or a local source/wheel path
innytypes addons list
innytypes addons outdated
innytypes addons update <id>               # or --all
innytypes addons enable <id>
innytypes addons disable <id>
innytypes addons pin <id>
innytypes addons unpin <id>
innytypes addons remove <id>

innytypes helper status
innytypes helper release <id>
innytypes telemetry status
innytypes telemetry show
innytypes telemetry on                     # or off
innytypes quit                             # add --force for a hung application

Installation is always explicit. In particular, innytypes up never mutates an addon environment. Use innytypes <command> --help for the complete options and platform-specific default paths.

Addon architecture

The dependency direction is intentional: addons depend on InnyTypes; InnyTypes never depends on an addon. The host does not import addon code. It reads the manifest recorded at install time, resolves addon dependencies, and starts each addon in its own process and environment.

An addon declares its identity, host API version, requirements, event kinds, stability and update policy, and settings schema. Event kinds are public APIs named <addon-id>.<name>.v<N>; changing a payload requires a new versioned kind. Settings are data, not widgets, so the host can validate, store, and draw the same declaration on every platform.

See plan 0001 for the host contract and the project Loop pack for the invariants contributors must preserve.

Development and verification

Run the canonical gate from the repository root:

./docs/loop/verify.sh

The gate creates or synchronizes its environment from the frozen lock, then runs formatting, linting, strict type checking, the branch-aware test suite and coverage checks, dependency-pin checks, secret scans, and the documentation/code consistency checks. It must finish with gate: GREEN from a clean checkout; tests must not depend on untracked local fixtures, Node, or a running Anytype instance.

Useful focused commands after uv sync --frozen are:

uv run --no-sync pytest
uv run --no-sync ruff check .
uv run --no-sync ruff format --check .
uv run --no-sync mypy

Plans live in docs/plans/, executable work-item records in docs/loop/inbox/, and implementation notes in docs/log.md. A change is complete only when its plan, tests, and code agree.

Packaging and current limitations

Briefcase configuration is included for native macOS, Windows, and Linux applications. Build on the target platform where required; Windows applications in particular must be built on Windows. A Linux Debian package has been produced in a container, and macOS is the platform exercised end to end today.

Current release constraints:

• Bundles are unsigned, so operating systems may warn on first launch.

• The Windows implementation is covered by tests, but a Windows package still needs a native build and package-level verification.

• Addon installation from a bundled application still needs the bundle to carry a wheel of the matching InnyTypes version; source-checkout installation already works.

• Release 0.1.0 is documented in CHANGELOG.md, but this repository has not yet established automated cross-platform CI or a tagged binary-release process.

License

InnyTypes is released under the MIT License.