★  Gen AI Summit Asia·August 2026 · Malaysia·Get your ticket →·★  Gen AI Summit Asia·August 2026 · Malaysia·Get your ticket →·★  Gen AI Summit Asia·August 2026 · Malaysia·Get your ticket →·★  Gen AI Summit Asia·August 2026 · Malaysia·Get your ticket →·
A terminal window showing LinkedIn messages synced as plain text files in a dark coding environment
AI Tools & ReviewsMay 18, 20268 min read

Allman: Open-Source LinkedIn DMs for AI Agents (CLI + TUI)

Allman is an MIT-licensed CLI that syncs LinkedIn DMs to local JSONL files. Pipe conversations to AI agents, search from your terminal, and own your data.

Reeve YewReeve Yew

Allman is an MIT-licensed, local-first CLI that syncs LinkedIn DMs to plain JSONL files on your disk. It lets you read, search, and reply to messages from your terminal, and pipe entire conversations to AI agents. No cloud. No subscription. Just files, git, and grep.

Every LinkedIn automation listicle in 2026 covers the same dozen SaaS tools: HeyReach, Dripify, Expandi. They all run in the cloud, charge monthly, and hold your conversation data on their servers. None of them expose a pipe-friendly interface for AI agents. Allman fills that gap, and this is the first hands-on breakdown of what it does, how it works, and whether it belongs in your agent stack.

What is allman and why does it exist?

Allman is a command-line tool built by Tarka AI under the MIT license. It syncs your LinkedIn direct messages to a local git repository as JSONL files. Every conversation becomes a file. Every message becomes a line of JSON. You read them with cat. You search them with grep. You track changes with git log.

The official site describes it plainly: "Messages are stored as plain JSONL in a git repo on your disk. No cloud sync, no telemetry. cat, grep, and git log work exactly as you'd expect." That one sentence explains why allman matters. Your LinkedIn DMs become data you control, not data locked inside a browser tab or a SaaS dashboard.

The tool ships as a standalone binary. Install it, authenticate with your LinkedIn session, run allman sync, and your conversations land on disk. From there, the data is yours. Pipe it to a script. Feed it to an agent. Back it up to a private repo. The tool does not care what you do with the files once they exist.

How does allman work under the hood?

The architecture is simple by design. Allman pulls your LinkedIn message history through LinkedIn's messaging endpoints and writes each conversation thread as a .jsonl file in a directory structure organized by contact. Each line in the file is a single message with metadata: sender, timestamp, body text, and read status.

The CLI repository on GitHub describes this as "a local-first, file-backed CLI for LinkedIn messaging" where "all reads come from disk." That means once you sync, allman never needs to call LinkedIn again to show you a conversation. Open the file. It is right there.

For sending replies, allman writes outbound messages through LinkedIn's API and appends the sent message to the local JSONL file simultaneously. Your local store stays in sync without a separate pull step. The git layer means you can diff any conversation over time. If a message was edited or deleted on LinkedIn's side, your local copy preserves the original.

What does the TUI look like?

The TUI (terminal user interface) is a separate package called allman-tui, described as "a thin React/Ink front-end over the on-disk allman message store and the standalone allman binary" with "vim-style navigation, inline search, emoji reactions." Think of it as a lightweight LinkedIn Messaging client that runs in your shell.

The TUI supports vim-style navigation. Press j and k to move between conversations. Hit / to search. Select a thread and the messages render inline with timestamps and sender names. You can reply directly from the TUI, and the outbound message writes to both LinkedIn and your local JSONL file.

For developers who live in the terminal, this removes the need to switch to a browser for LinkedIn messaging. For non-developers, the TUI is a friendlier entry point than raw CLI commands. Either way, the data layer underneath is the same: plain files on disk.

Why does local-first matter for LinkedIn DMs?

Most LinkedIn automation tools are cloud-hosted. Your messages flow through someone else's server. You pay monthly for access to your own conversations. If the service shuts down, your message history goes with it.

Allman inverts that model. Your data sits on your machine, in files you can open with any text editor. No vendor can revoke access. No subscription lapse can lock you out. The JSONL format is not proprietary. Five years from now, those files will still be readable by any tool that handles JSON.

This matters more when agents enter the picture. If you want an AI agent to process your LinkedIn conversations, it needs access to the data. With SaaS tools, that means API keys, OAuth flows, and trusting a third party with your messaging content. With allman, the agent reads files from a directory. The data never leaves your machine unless you send it somewhere.

How do AI agents use allman in practice?

The most direct pattern is piping. Run allman search "project proposal" and pipe the output to an agent. The agent receives structured JSON and can summarize, draft a reply, flag action items, or sort conversations by priority.

A more advanced pattern uses allman's NDJSON event stream. When new messages arrive during a sync, allman emits them as newline-delimited JSON events. An agent listening on that stream can react in real time: new message arrives, agent reads it, agent drafts a response, agent writes the reply back through allman.

If you have already explored how to set up your first AI agent with MCP tools, adding allman is straightforward. Your agent shells out to the allman binary, reads the JSONL output, and acts on it. No special SDK. No MCP server required (though one could be built on top of allman's file layer).

This design philosophy mirrors what e2a does for email. E2a turns email into a programmable data layer for agents. Allman does the same for LinkedIn DMs. Together, they cover the two channels where most professional conversations happen.

How does allman compare to other LinkedIn CLI tools?

The closest alternative is Linked API's LinkedIn CLI, which provides structured JSON output for agent parsing. But there is a fundamental difference: Linked API routes everything through their cloud infrastructure and charges for access. Allman runs entirely on your machine.

OpenOutreach is another open-source option, but it focuses on outbound lead generation with AI-powered lead finding. It is not built to be a general-purpose messaging data layer. Allman does not try to find leads or automate outreach sequences. It treats your existing DMs as data and gives you tools to work with that data.

The SaaS automation tools (HeyReach, Dripify, Expandi, and others) solve a different problem entirely. They automate LinkedIn actions at scale: connection requests, follow-up sequences, profile visits. Allman does none of that. It reads and writes messages. That narrow focus is a strength if you want a clean data layer for agents, and a limitation if you want full LinkedIn automation.

For readers comparing the best AI coding agents in 2026, allman is not a coding agent itself. It is a data source that coding agents (and any other agents) can consume. The pattern is: agent shells out to allman, gets structured data back, decides what to do.

What are the risks and limitations?

LinkedIn's official policy on prohibited software and extensions explicitly states that you must not "use bots or other unauthorized automated methods to access the Services, add or download contacts, send or redirect messages." The policy does not draw a clear line between "exporting your own data" and "automating access." Allman syncs your messages locally, which is closer to a personal backup than a spam bot. But LinkedIn's enforcement is pattern-based, not intent-based.

If your account syncs every 30 seconds and sends 200 replies per hour through an agent, LinkedIn will likely flag it. If you sync once a day and read your messages locally, the risk is much lower. The tool itself is neutral. The risk depends on how you use it.

Other limitations worth noting:

  • Authentication depends on browser session tokens. LinkedIn does not offer a public messaging API. Allman works with session cookies, which can expire or get invalidated.
  • No attachment handling yet. The CLI syncs text messages. File attachments, images, and voice messages are not included in the current JSONL output.
  • Early-stage project. The GitHub repositories are young. Documentation is thin. Expect rough edges. If you need production-grade reliability today, this is not ready.
  • Single-account only. There is no multi-account management. Each allman instance maps to one LinkedIn session.

What are the common pitfalls when setting up allman?

Stale session tokens. LinkedIn sessions expire. If allman stops syncing, the first thing to check is whether your session token is still valid. Re-authenticate through your browser and update the token.

Git repo size over time. If you have thousands of LinkedIn conversations, the JSONL files add up. Git handles text files well, but large repos slow down git log and git diff. Consider archiving older conversations to a separate branch or repo.

Over-automating replies. It is tempting to build an agent that auto-replies to every incoming DM. Do not do this. LinkedIn monitors reply patterns. Rapid, templated responses from an API-like pattern will trigger restrictions. Use agents to draft replies. Review them before sending.

Mixing personal and professional accounts. If you use LinkedIn for both personal networking and business outreach, allman syncs all conversations from the authenticated account. There is no built-in filtering. Set up your agent pipelines to handle both types of messages, or use a dedicated LinkedIn account for agent workflows.

Skipping the git layer. Allman stores files in a git repo for a reason. If you skip git commit after syncing, you lose the ability to diff and track changes. Make syncing and committing part of the same workflow. A simple cron job handles this: allman sync && cd ~/.allman && git add -A && git commit -m "sync".

Who should use allman today?

Allman is not for everyone. It is for a specific type of builder.

If you are a developer or technical operator who already works in the terminal, allman fits naturally into your workflow. You get LinkedIn DMs as data files alongside your code, your notes, and your other CLI tools.

If you are building AI agents that need access to professional messaging data, allman is one of very few options that does not require a cloud subscription. The JSONL format is trivially parseable by any language, any framework, and any agent runtime.

If you are a non-technical user who wants easier LinkedIn messaging, allman is probably not for you yet. The TUI helps, but setup still requires comfort with the command line, session tokens, and git.

If you run outreach at scale and need LinkedIn automation features (sequences, connection requests, profile visits), allman is not the right tool. It handles messages and only messages.

What comes next for allman?

The project is early. The GitHub repos have limited stars and minimal community contribution so far. But the architecture is sound, and the timing is right. More builders are wiring agents to real-world data sources in 2026 than ever before, and LinkedIn DMs remain one of the least accessible channels for programmatic access.

A few things to watch for:

  • MCP server support. Wrapping allman as an MCP tool server would let Claude Code, Cursor, and other agent environments access LinkedIn DMs natively. The file-backed design makes this straightforward to build.
  • Multi-platform expansion. The same JSONL-on-disk pattern could apply to Twitter DMs, WhatsApp, Telegram, or Slack. If Tarka AI builds adapters for other platforms, allman becomes a universal messaging data layer.
  • Community plugins. The MIT license invites forks and extensions. Expect to see agent templates, notification integrations, and custom sync schedules from the community.

For now, allman is a sharp tool that does one thing well. It turns LinkedIn DMs into files. What you build on top of those files is up to you.

Explore more tools and reviews in our AI tools and reviews pillar. If you are building with agents and want to stay current on tools like allman, join AI Masterminds, the community where builders share what is working right now.

FAQ

Is allman free to use?

Yes. Allman is released under the MIT license, which means you can use it, modify it, and distribute it for free. There are no paid tiers, no cloud subscriptions, and no usage limits baked into the tool itself. The code is open on GitHub under the tarkaai organization. You install it locally and run it from your terminal. The only cost is the machine you run it on.

Does allman violate LinkedIn's terms of service?

LinkedIn's official help center lists bots and unauthorized automated methods as prohibited software. Allman syncs your own DM history to local files, which is closer to exporting your data than automating outreach. But the line between 'personal data export' and 'automated access' is not clearly drawn in LinkedIn's policy. If you use allman to mass-send messages through an agent, you are almost certainly in violation. If you use it to read and search your own conversations locally, the risk is lower but not zero. Read LinkedIn's policy yourself before deciding.

How does allman compare to LinkedIn CLI by Linked API?

Linked API's LinkedIn CLI requires a paid cloud subscription and routes your data through their servers. Allman stores everything as JSONL on your local disk with no cloud dependency. Linked API gives you more LinkedIn actions (profile views, connection requests, posting). Allman focuses narrowly on DMs and treats them as a file-backed data layer. If you need full LinkedIn automation, Linked API is more complete. If you want local-first, privacy-respecting DM access for agents, allman is the better fit.

Can I use allman with Claude Code or Cursor?

Yes. Both Claude Code and Cursor can shell out to CLI tools. Since allman reads and writes JSONL files on disk, any agent with file access and shell access can use it. You can pipe allman output to an agent, or have the agent call allman commands directly. There is no MCP server yet, but the NDJSON event stream means agents can subscribe to new messages in real time through a simple pipe.

What happens to my data when I use allman?

Your messages stay on your machine. Allman stores conversations as plain JSONL files inside a local git repository. There is no cloud sync and no telemetry. You can inspect every file with cat or grep, review history with git log, and delete everything by removing the folder. This is the opposite of SaaS tools that hold your messaging data on their servers.

Sources

  1. allman — every DM, one terminal · allman.sh (first-party)
  2. tarkaai/allman-cli on GitHub · GitHub (official repo)
  3. Prohibited software and extensions — LinkedIn Help · LinkedIn (official policy)
  4. tarkaai/allman-tui on GitHub · GitHub (official repo)

More where this came from

Documentation, not the product.

See all posts →