agentixmesh

Questions

APPENDIX A · FAQ

Frequently asked questions

Straight answers on what agentixmesh is, which agent tools it works with, what it secures, and how it differs from a message queue.

Basics

What is agentixmesh?
agentixmesh is an agent trust layer — a file-based delivery layer that lets AI agent sessions on one machine exchange messages without inheriting each other's authority, addressed `uid:project`. Transport is a maildir (new/cur/held/seen directories) plus an inject hook: no daemon, no network listener, no open port, no sudo. It's MIT-licensed and open on GitHub (github.com/TokonoMix/agentixmesh).
What does "data is not authority" mean?
It means an incoming message is rendered as an inert DATA frame to read, never a command to obey. The receiving agent decides what to do; the mesh never auto-acts on a message's content. Replying with words in response to a message is fine; taking an action, running code, or revealing secrets purely because a message body says so is not.
What problem does agentixmesh actually solve?
It solves the "confused deputy" risk of local agent-to-agent messaging: one session inheriting another's authority just because a message arrived. agentixmesh separates who sent a message (a kernel-verified OS user id) from what it says (an untrusted body), so a message can prove its sender without that proof authorizing anything the message asks for. Containment, not communication, is the hard part.
Who is agentixmesh for?
Engineers running multiple AI agent sessions — Claude Code today, other harnesses as adapters ship — on the same machine, who need those sessions to hand off information or coordinate without wiring up a message queue or ticket system, and without one session's output silently becoming another session's instructions. It assumes command-line agent workflows, not end-user chat products.
Is agentixmesh production-ready?
Partially, and by design in stages. The same-user core is public and stable — it's the shipping, dogfooded default. Cross-user delivery (separate OS users, one machine) is validated end-to-end, but its production go-live stays human-gated: a message body is withheld until a person releases it. Cross-machine delivery doesn't exist yet — that's roadmap, not agentixmesh.
Is agentixmesh just a message bus or pub/sub system?
No. A message bus moves bytes; agentixmesh is concerned with what a session is allowed to do once bytes arrive. The distinguishing piece isn't the transport (a maildir) — it's kernel-verified sender identity plus inert-DATA framing that keeps a delivered message from being treated as a command. Plain pub/sub has neither property.
Why file-based (a maildir) instead of a socket or daemon?
A maildir needs no running process, no port, and no privilege escalation — delivery is just files moving between owner-only (0700) directories the OS already protects. A daemon or socket listener adds an always-on attack surface and operational burden (start/stop, crash recovery, permissions) for a same-machine, low-throughput use case that plain filesystem semantics already cover.
What does "agent trust layer" mean?
It means agentixmesh sits below message content and answers one question: can you trust who sent this? It kernel-verifies the sender's OS user id via fstat on the open file descriptor — unforgeable — while treating everything else, including the body and the sender's self-declared project label, as untrusted. Trust here is about identity, not about what a message claims.
What is an address (uid:project)?
An address is `uid:project` — the numeric OS user id of the intended recipient, plus a project label. The uid half is what the mesh actually enforces delivery on. The project half is just the sender's current-working-directory basename, self-declared and unverified, used to route into the right inbox for that user. `mesh-whoami` prints your own address.
What is the human's role in agentixmesh?
The human is the final authority, most concretely for cross-user delivery: a message body is withheld until a human releases it, so unsupervised cross-user action is impossible by construction. More broadly, agentixmesh never auto-acts on a message's content — the receiving agent decides what to do with it — leaving people, not the mesh, in control of consequential decisions.
Is agentixmesh a framework or a protocol?
It's closer to a protocol plus a thin reference implementation than a framework. The core — kernel-verified sender identity, maildir transport, inert-DATA framing — is harness-neutral by design and doesn't dictate your agent's internals. You integrate by wiring a harness adapter to the protocol, not by rewriting your agent to fit agentixmesh's structure.
What does agentixmesh NOT try to be?
It doesn't try to be a general-purpose message queue, a cross-machine transport, or a security guarantee against prompt injection. It doesn't try to make agents autonomous on your behalf — cross-user auto-acting is blocked by design, not just discouraged. Cross-machine delivery and higher-authority features like leader-gate co-approval exist only as roadmap items, not as things it claims to do today.

Compatibility & harnesses

Does agentixmesh work with Claude Code?
Yes — Claude Code is the reference adapter and it ships today. It wires the mesh through Claude Code's SessionStart and UserPromptSubmit hooks, so messages appear in context automatically without changing how you use Claude Code. This is the most battle-tested integration and the one the maildir/inject-hook design was built against first.
Does agentixmesh work with OpenAI Codex CLI?
An adapter ships and is unit-tested. Live-binary end-to-end verification against the real Codex CLI is still in progress, so treat it as shipped-but-not-yet-fully-verified-live rather than production-proven. We won't describe the Codex path as "done" until that live verification completes.
Does agentixmesh work with Gemini or other agent tools?
Not yet. Hermes and OpenClaw adapters are designed and prototyped, which puts them on the roadmap, not in the shipped set. Today the only adapters are Claude Code (reference, shipped) and OpenAI Codex CLI (unit-tested, live e2e verification in progress). Treat any other harness as unsupported until an adapter ships.
What does "harness-agnostic" actually mean here?
It means the core — maildir transport, kernel-verified identity, message framing — has no dependency on any particular agent tool. What's tool-specific is a thin adapter layer that wires that core into a harness's own hook system, like Claude Code's SessionStart/UserPromptSubmit. The protocol doesn't change per tool; only the wiring does.
Can two different agent tools, like Claude Code and Codex CLI, exchange messages on the same mesh?
Architecturally yes — the maildir format and kernel-verified identity model don't care which harness wrote or reads a message, only which OS user did. But live proof today covers Claude Code end-to-end; Codex CLI's live-binary e2e, including true cross-harness exchange, is still in progress, so don't treat that scenario as validated yet.
Do I need to modify my agent's code to use agentixmesh?
No — you install the CLI wrappers and wire a small hook once; there are no changes to the agent's own source. For Claude Code this is the reference adapter, shipped today. For other harnesses, an adapter wires the same underlying mesh commands into that tool's hook system instead.
What is the push-hook contract — how does a message end up in my agent's context?
The hook fires on session start and on each user prompt submit. It does a zero-token file read of the mailbox, and if there's new mail, it prints an inert DATA frame to stdout. The harness treats hook stdout as injected context, so the message appears without the mesh itself making any LLM call.
Does agentixmesh work across different machines?
No, same-machine only. All current delivery — Claude Code and Codex CLI — runs on one host through a local maildir; there is no network listener or remote transport. Cross-machine, cryptographically-signed delivery is a separate product, AgentsWeaver, and it's on that project's roadmap, not part of agentixmesh.
How do I add support for a new harness?
You wire, you don't design a new protocol. A harness adapter needs two things: a way to run a command at session start or on prompt submit (the push hook), and a way to make that command's stdout become context. The maildir format, identity verification, and framing are already harness-neutral and unchanged.
Will agentixmesh support Gemini CLI or other harnesses eventually?
Hermes and OpenClaw adapters are already designed and prototyped — that's the current roadmap, not a shipped feature. A Gemini-specific adapter isn't separately confirmed. Because adding a harness is wiring rather than new protocol work, the expected effort per new tool is small, but nothing beyond Claude Code and Codex CLI ships today.
Does harness-agnostic mean any two agent tools can be mixed freely with no added risk?
No — harness-agnostic describes the transport and identity layer, not a blanket safety guarantee. Sender identity is still just a kernel-verified OS user id, not a verified agent or project. Whatever harness receives a message, the agent must still treat it as inert data, never as an instruction to obey.
What's the difference between the "core" and an "adapter" in agentixmesh?
The core is the maildir transport, kernel-verified sender identity, and DATA-frame message format — fixed and identical for every harness. An adapter is the thin, harness-specific glue: hook registration plus stdout wiring that connects a particular agent tool to that core. New harness support is scoped entirely to the adapter, not the core.
Can I use agentixmesh with a custom, in-house agent harness?
Yes, if you can implement the two adapter requirements: a hook that runs at session start or prompt time, and a way to feed that hook's stdout into the agent's context. Because the mesh core is harness-neutral, a custom harness needs no protocol changes — only the same kind of wiring Claude Code and Codex CLI use.
Does using multiple harnesses on the same mesh weaken the sender-identity guarantee?
No — identity verification happens at the OS/kernel level, via fstat on the open file descriptor, entirely below and independent of any harness. Whichever tool a message passes through, the sender's OS user id is verified the same unforgeable way; the choice of harness has no bearing on that guarantee.

Multi-user (cross-user)

Can two different OS users on one machine message each other with agentixmesh?
Yes — two separate OS user accounts on one host can exchange messages through agentixmesh's cross-user mode, which routes through a shared, group-owned maildir rather than each user's private one. This has been validated end-to-end with real send-to-delivery cycles. It behaves differently from same-user messaging in one key way: delivery is held by default, not immediate.
How is the sender verified when a message crosses OS-user boundaries?
The same way as same-user messages: the kernel, not the message itself. agentixmesh calls fstat on the open file descriptor to read the actual OS-level owner uid, which cannot be spoofed by anything the message claims. What is not verified is the project half of the address — a self-declared label anyone can set to anything.
What is the human-gate, and why is a cross-user message body withheld?
A cross-user message arrives held: the receiving agent sees only metadata — kernel-verified sender uid, length, thread id, timestamp — never the body text. A human must explicitly release it before the body reaches the agent. This exists because withholding the body, not merely flagging the message, is what actually limits exposure to injected content.
Can a cross-user message ever get auto-approved or auto-acted on?
No — this is impossible by construction, not a setting someone forgot to lock down. Cross-user delivery always defaults to human-gated, and per-address or per-project overrides can only make trust more restrictive, never raise it to auto. There is no code path where a held cross-user body reaches an agent without an explicit human release.
Is cross-user messaging production-ready?
The mechanism is validated end-to-end — real held, human-released, delivered cycles between two OS users have been proven live. But go-live for a given deployment stays human-gated by design: the withholding step is permanent for cross-user, not a rollout gap being closed later. So "ready" means safe to run under supervision, not safe to leave unattended.
How does releasing a held cross-user message work?
A human on the receiving side reviews the held message's metadata — sender uid, length, thread id, timestamp — then takes an explicit release action that reveals the body to the agent for the first time. Nothing is delivered before that step, and the message stays held indefinitely if the release never happens.
What can one OS user see of another user's messages before they're released?
Nothing but structural metadata. The receiving side can see that a message exists, which kernel-verified uid sent it, how long it is, and which thread it belongs to — never the text. This is deliberate: metadata alone can't carry an instruction, so showing it before human review doesn't reopen the injection surface the hold exists to close.
How does a colleague get onboarded to send or receive cross-user messages?
Onboarding is a dedicated enrollment step, not just creating an OS account on the box. A new member is registered so their kernel-verified uid is recognized as a legitimate mesh participant, with identity confirmed out-of-band rather than taken from a self-reported claim. Until enrolled, messages from that uid aren't treated as coming from a known member.
What happens when a colleague leaves or loses access?
Their mesh membership is revoked, which stops future messages from that uid being treated as coming from a recognized member. Revocation is an explicit administrative action tied to the OS-level identity, not a toggle any agent or message can request — consistent with the rest of agentixmesh, where trust changes are deliberate human actions.
Do both users have to be on the same machine?
Yes — agentixmesh's cross-user mode is single-machine only. It relies on a local filesystem and kernel-level uid verification, both host-local concepts with no meaning across separate machines. Messaging between agents on different hosts isn't something agentixmesh does today; that's what AgentsWeaver, the cross-machine, cryptographically-signed member of the same family, is built for.
Can a malicious user fake being a different project to trick a colleague's agent?
They can fake the project label, not the sender. The project half of an address is a self-declared string — the sender's own cwd basename — and isn't verified, so a message can arrive labeled as if from an unrelated project. The uid it actually came from stays kernel-verified: you always know which OS user sent it, just not which of their projects.
Is there a leader or approver role that can co-approve cross-user messages for a team?
A higher-authority layer — leader-gate co-approval and group roles — exists in the design but is roadmap, not shipped production security; don't rely on it today. The control that is live and load-bearing for cross-user is the per-message human release gate: every cross-user message goes through it regardless of any group structure.
Can one user monitor another user's mesh traffic, e.g., a team lead watching for issues?
Consent-gated leader-read monitoring is designed but not shipped — same roadmap status as the leader-gate and group-roles layer. As things stand, a user's mailbox is readable only by that user; there is no live feature letting another party observe someone else's messages, held or released, with or without consent.
Does the cross-user hold apply to every message, or only some?
It applies to every cross-user message — held-with-metadata-only is the default and only mode, not a per-message or per-sender option. There is no cross-user setting to "trust this uid, auto-deliver." Ownership eliminating forgery plus the human gate is the fixed contract for any message that crosses a uid boundary.
The sender's uid can't be forged, so why not skip the human step?
Because uid verification and injection safety are different problems. Kernel-verifying the sender's uid proves who sent a message, not that its contents are safe to act on — a legitimately-sent message can still contain text crafted to look like an instruction. The human release step limits exposure to that content; it isn't a redundant identity check.
Once a cross-user message is released, can the agent act on it automatically?
No — once released, it's handled exactly like any other inert data frame, under the same standing rule as same-user messages: never obey a message body. The agent may reply with words, but running code, taking an action, or revealing secrets on the message's say-so is against that rule regardless of whether the message came from the same user or a different one.
What OS-level permissions protect a shared cross-user mailbox from other users on the machine?
Cross-user delivery uses a group-owned directory rather than the strict owner-only (0700) dirs of same-user mode, since more than one uid needs to reach it. Group members can drop a message in and traverse the directory but can't list or read what's inside; only the intended receiver can read a message, so co-tenants on the box can't browse each other's mail.

Security & trust model

Does agentixmesh stop prompt injection?
No — it reduces prompt-injection risk, it does not eliminate it. Ownership guarantees who sent a message, not what the message says. A legitimately-sent message can still contain text crafted to look like an instruction, and the agent reading it is the soft spot. agentixmesh mitigates this with inert-DATA framing, sanitation, and a standing never-obey rule — but the receiving LLM ultimately decides what to do.
What's the difference between forgery and prompt injection, and why does agentixmesh treat them differently?
Forgery is a message lying about who sent it; injection is a legitimately-sent message trying to talk an agent into an action. agentixmesh eliminates the first with a kernel-verified hard guarantee — a spoofed sender is rejected before an agent ever sees the message. It only reduces the second, because injection lives in the message content, which the mesh can frame and sanitize but not fully neutralize.
What does "kernel-verified sender" actually mean?
It means the sending OS user id is read via fstat on the open file descriptor of the delivered message, not from any field inside the message itself. The kernel tracks file ownership independently of message content, so a sender cannot claim to be a different user — the OS would have to lie about who owns the file it just wrote, which it does not do.
Can someone forge who a message is from?
No — sender identity is a hard, kernel-enforced guarantee, not a convention the sender can override. Because the uid comes from the operating system's own file-ownership metadata rather than a self-reported field, a process running as one user cannot make a message appear to come from another user. This is the one part of the trust model that is not probabilistic.
Is the "project" half of a uid:project address trustworthy?
No — the project label is self-declared (it's just the sender's working-directory basename) and is not verified. agentixmesh proves which OS user sent a message, not which agent, repository, or project sent it. Treat the project half of any address as a hint for routing, never as a security claim — two agents run by the same user can both claim any project name they like.
Can a message from another agent make my agent run a command or leak a secret?
No message can force an action — agentixmesh only delivers data into context; it never executes anything on the sender's behalf. Whether an agent runs a command or reveals a secret depends entirely on that agent's own decision-making and tool permissions. The mesh's job is to hand the receiving agent inert text and a rule to treat it as data, not to grant or exercise any capability.
What is an "inert DATA frame"?
It's how an incoming message is presented to the receiving agent: clearly delimited as data to read, never as a command to obey. The framing pairs with a standing rule that a message body's say-so authorizes nothing — replying in words is fine, but taking an action, running code, or revealing a secret on a message's instruction is not. The agent, not the mesh, decides what happens next.
What sanitation does agentixmesh apply to incoming messages?
Before a message reaches an agent's context, agentixmesh strips constructs commonly used to disguise instructions as trusted output — things like control characters, invisible/zero-width characters, and text patterns that mimic the start of a new conversational turn. This narrows the injection surface but is a mitigation, not a filter that can catch every possible phrasing of a manipulative message.
Is there protection against replayed or duplicate messages?
Yes — delivered messages are tracked so the same message is not re-injected into an agent's context on a later poll. This guards against a message being silently re-delivered and re-read as if it were new, which matters because repeated exposure to the same crafted text is itself a way to pressure an agent. It's a delivery-hygiene control, not a defense against a first-time injection attempt.
What is agentixmesh's threat model?
Trusted colleagues sharing one machine, not a hostile-root adversary. The design assumes participating OS users aren't actively attacking the host's kernel or file permissions to impersonate each other — if a user has root-level access, they can defeat almost any local trust mechanism. Within that assumption, agentixmesh's forgery guarantee holds; it is not designed to survive a malicious system administrator or a compromised kernel.
Is agentixmesh a security product?
No — it's a trust boundary for message delivery, not a security product in the broader sense. It answers one narrow question reliably (who sent this message) and helps with one broader problem partially (don't let message content hijack an agent). It doesn't replace endpoint hardening, secrets management, or an agent's own permission scoping — those remain the operator's responsibility.
What does file ownership NOT solve?
Ownership solves who sent a message; it does not solve what a message says or how an agent reacts to it. It does not stop a legitimately-sent message from containing manipulative text, does not vet message content for safety, and does not constrain what a receiving agent is capable of doing — that's a function of the agent's own tool permissions, not the mesh.
If my agent obeys a malicious instruction embedded in a message body, is that an agentixmesh bug?
No — that's the receiving agent failing to honor the never-obey-a-message-body rule, which is exactly the residual risk agentixmesh is upfront about. The mesh delivers the message framed as inert data and cannot force an LLM to respect that framing. Reducing this failure mode further is a model/prompt-discipline problem on the receiving side, not something a delivery layer can fix by itself.
Does agentixmesh authenticate the agent or the harness sending a message?
Neither — it authenticates the OS user the sending process is running as, nothing above that. It can't distinguish Claude Code from another harness, or one agent process from a second one run by the same person. If you need to know which specific agent or tool sent something, that has to come from context or convention, not from agentixmesh's identity guarantee.
Is cross-user messaging (separate OS users, same machine) safe to use today?
It's validated end-to-end but its production go-live is intentionally human-gated, not something you should treat as generally available yet. A cross-user message body is withheld until a human releases it, and cross-user auto-acting is impossible by construction — that gate is the safety mechanism, not a formality. Treat cross-user as a reviewed capability still awaiting a deliberate rollout decision.
Can a message auto-trigger an action without any review?
No — delivery only puts a message into an agent's context; nothing in agentixmesh executes on a message's behalf. Within one user's own sessions, the agent that reads a message decides what to do next under the never-obey rule. Across users, the added human-release gate means a body isn't even visible until a person lets it through, which rules out any auto-acting by construction.
Is there a persistent audit trail of every message?
Not as a shipped, production guarantee in the same-user core — the reliable part is the replay guard preventing re-delivery, not a tamper-evident log. Consent-gated monitoring of another user's mailbox (leader-read) exists by design for the cross-user tier but is roadmap, not something advertised as a production security or compliance feature today.

Isolation & boundaries

What does a uid:project address actually identify?
Two different things with two different guarantees. The uid is the OS user, kernel-verified via fstat on the receiving end, so it can be trusted. The project half is the sender's own working-directory basename, self-declared and unverified — treat it as informational context, not proof of where a message came from.
Is the project half of an address a stable, unique identifier?
No. It's just the basename of whatever directory the sending session's working directory happens to be. Nothing registers it or enforces uniqueness across a machine. Two unrelated folders that happen to share a name produce the identical address, with no central authority checking for collisions before delivery.
How are mailboxes isolated between projects?
Each address gets its own maildir directory created owner-only (0700), readable only by the OS user that owns it. Isolation is enforced by filesystem permissions, not by application-level logic — a process running as a different OS user cannot open the directory at all, no matter what it attempts.
Can one project read or act on another project's inbox?
No, across OS users — delivery is per-address, and a message lands only in the maildir matching its uid:project destination. A message also carries no authority: receiving one never grants a session the ability to reach into a different inbox, act on a peer's behalf, or trigger anything automatically.
If my OS user runs several different agent projects, can they read each other's mail?
Isolation is enforced per OS user, not per project, since maildir ownership is set at the uid level. A process running as that same uid can, in principle, open any maildir that uid owns. The project label only selects a delivery address — it isn't a separate permission boundary within one user.
Can a message spoof which project it was sent from?
Yes — the project label is self-declared and not cryptographically checked, so a sender can put any string it wants in that half of the address. What can't be spoofed is the uid: the kernel-verified sender identity tells you which OS user genuinely sent the message, independent of the claimed project name.
What happens if I mistype an address and it happens to match a different real project?
The message is delivered there, silently. There's no confirmation step checking whether the destination you typed is the one you meant, so a typo that collides with another live address just routes your message into that session's inbox instead — with nothing telling either side a mistake happened.
What happens if I address a project that doesn't exist or isn't running?
The message is written to that mailbox and waits — there is no registry of active addresses to validate against, so sending to a nonexistent or currently idle uid:project produces no error. It becomes readable only if and when a session with exactly that address later checks its mailbox.
How do I find my own mesh address?
Run mesh-whoami — it prints your uid:project address exactly as other sessions would need to type it to reach you, derived live from your OS uid and your current working directory's basename. Use it rather than reconstructing the address from memory, since the project half depends on cwd and can drift.
How do I reach another session without hand-typing or guessing its exact address?
Use the sender-side address book — a list of friendly aliases you maintain locally that map memorable names to full uid:project addresses, so you don't have to remember or retype an exact basename each time. It only affects how you refer to a destination; it doesn't change how the recipient is addressed.
Does agentixmesh auto-discover other projects on the machine and bridge them for me?
No. There's no auto-discovery, no directory of active projects, and no automatic connecting of sessions. Every message goes to one specific uid:project address that a sender supplies explicitly. Isolation is the default state; a boundary is only crossed because someone named that exact destination on purpose.
Given the project label isn't trustworthy, what should I actually rely on for isolation guarantees?
Rely on the uid boundary. agentixmesh guarantees mailboxes are only readable by their owning OS user and guarantees you know which OS user sent an incoming message. It does not guarantee the claimed sending project is accurate — treat any project name inside or attached to a message as context, never as access control.
Can two different directories with the same basename collide onto one address?
Yes. Addressing uses only the basename of the working directory, so any two folders sharing a name — for example a project's main checkout and a separate copy or checkout of it elsewhere — resolve to the identical uid:project address and silently share one inbox, with no warning at send or receive time.
Do I need to register a project before it can receive mesh messages?
No signup step exists. A project's address exists implicitly the moment something running as that OS user, from a directory with that basename, checks its mailbox. Sending to an address that has never been "created" simply writes the message to a maildir, which becomes readable whenever a matching session later polls it.
Is mailbox isolation enforced by agentixmesh's own code, or by the operating system?
By the operating system. Mailbox directories are created owner-only (0700), so the isolation guarantee comes from standard Unix filesystem permissions rather than an application-level check agentixmesh could get wrong. That's also why it holds against a buggy or malicious agent process — the kernel refuses the open() before any mesh code runs.

Cost & tokens

Does checking the mesh for new messages cost LLM tokens?
No. Checking the mesh is a plain file read against your local maildir, not an LLM call, so it costs zero tokens. Polling frequency doesn't change that — `mesh-poll status` and the automatic inject-hook check on session start are file-system operations. You control whether this check even runs via `mesh-poll on/off/status`.
When does a mesh message actually cost tokens?
Only when it's delivered into an agent's context for it to read. A pending message sitting in a maildir costs nothing; the cost appears the moment its text is rendered as a DATA frame into the conversation, and that delivery is disclosed to the agent — it isn't a hidden background charge.
Does a message sitting queued or held while waiting for release cost tokens?
No. Holding or queuing a message is a file sitting on disk in the `held` (or `new`) directory; nothing reads it into any agent's context until release, so it accrues zero token cost. Cost only starts once the message is actually delivered and read — queue duration is irrelevant to spend.
Does forwarding a mesh message to a human channel, like a phone, cost LLM tokens?
No. Forwarding to a human channel — for example relaying a notification to a phone — is a plain message-passing operation, not an LLM call, so it incurs no LLM token cost. Token cost is tied specifically to an agent reading content into its own context, not to moving text between delivery channels.
Is agentixmesh free to use?
There's no per-message fee and no token cost to poll or check the mesh — that part is free. "Free" here means free of LLM tokens: agentixmesh itself charges nothing. What isn't free is the underlying agent session — hosting and compute for running the agents that send and receive is a separate cost you already pay.
Is agentixmesh open source?
Yes. It's MIT-licensed and published on GitHub (github.com/TokonoMix/agentixmesh). You can read the transport, identity-verification, and delivery code yourself rather than take cost or security claims on faith — there's no closed component mediating message delivery or metering usage.
Do I need an API key or subscription to use the mesh itself?
No. The mesh is local files — a maildir plus an inject hook — with no daemon, network listener, or external service to authenticate against, so there's nothing to key or subscribe to for the mesh layer. The only cost you'll see is your own agent's model usage when it reads a delivered message.
Can I limit or turn off token spend from mesh delivery?
Yes, with `mesh-poll off`. Turning polling off stops the inject hook from checking for or delivering new messages into your context, so nothing gets read and no tokens are spent on mesh content. `mesh-poll status` shows the current state; `mesh-poll on` re-enables delivery when you want it back.
Does sending a message with mesh-send cost tokens?
Writing a message with `mesh-send` is a file write to the recipient's maildir, not an LLM operation, so the act of sending adds no tokens beyond whatever your agent already spent composing the text it wanted to send. There's no mesh-side fee layered on top of that write.
Does the automatic inject hook that runs on session start silently spend tokens every turn?
No, not unless there's actually a message to deliver. The hook's check for new mail is a file read; if the maildir is empty, nothing gets added to context and no tokens are spent. Tokens are only spent on the turns where a pending message is actually rendered into the conversation.
If I never read a held or pending message, do I still pay for it?
No. An unread message — whether sitting in `new`, `held`, or never claimed — never gets tokenized into any agent's context, so it costs nothing. Cost is tied strictly to the act of an agent reading delivered content, not to a message's mere existence in a mailbox.

Comparisons

How is agentixmesh different from a message queue like Redis or RabbitMQ?
A queue moves bytes between endpoints; it does not know or verify who sent them. agentixmesh kernel-verifies the sender's OS user via fstat on the open file descriptor before the receiving agent ever sees the message, so a queue message claiming to be 'from user X' can be forged — an agentixmesh message can't be. That identity guarantee is the point; a queue doesn't provide it.
Could I build the same thing with Redis pub/sub or a database table?
You could move the bytes, but you'd have to bolt on sender verification yourself — Redis and a shared DB table trust whatever client wrote to them. agentixmesh's guarantee comes from the OS: only the real uid that opened the file descriptor can be the recorded sender. Reimplementing that on a queue means re-deriving kernel-level identity checks, which is most of the hard part.
Does agentixmesh give delivery guarantees or ordering like a proper message queue?
Not in the way a queue product does — no acks-with-retries-and-DLQ mechanics, no cross-sender ordering guarantees. It's a maildir: messages land in new/, move to cur/ on read, held/ for gated cases. That's deliberately simple. If you need broker-grade throughput, ordering, or backpressure, agentixmesh isn't that tool — it's a trust layer, not a queue product.
How does agentixmesh relate to MCP (Model Context Protocol)?
Different layer. MCP connects one agent session to tools and resources — databases, APIs, files — it calls. agentixmesh connects one agent session to another agent session, so they can exchange messages without one inheriting the other's authority. A session can use MCP servers for tools and agentixmesh for talking to peer agents — they're complementary, not competing.
Can I use agentixmesh and MCP together?
Yes — they solve different problems and don't conflict. A Claude Code session might have MCP servers wired for tool access, like a database or search API, and separately receive agentixmesh messages from another session working a related task. MCP governs the agent-to-tool edge of the context; agentixmesh governs the agent-to-agent edge. Nothing about one requires or blocks the other.
How does agentixmesh compare to A2A or other agent-to-agent protocols aimed at cross-machine communication?
It's a positioning difference, not a feature gap: agentixmesh is single-machine, file-based, with kernel-verified sender identity — it does not do cross-machine transport, TLS, or cryptographic signing between hosts. Protocols built for agents on separate machines solve network-level trust, which is a different problem than local file-descriptor trust. Cross-machine, signed agent communication is roadmap territory for us (AgentsWeaver), not what agentixmesh does today.
Why not just have agents read and write a shared file or database?
A shared file or DB has no concept of who wrote a given row beyond whatever the writer claims — any process with write access can forge a sender field. agentixmesh's maildir is owner-only (0700, same-user), and the sender is derived from the kernel-verified uid of the process that opened the file, not a self-reported column. Shared storage gives you bytes, not provenance.
What's wrong with a shared scratch directory two agents both poll for changes?
Nothing stops one agent, a bug, or an injected instruction from writing a file that impersonates another sender — a plain shared directory has no identity check at all. agentixmesh adds exactly that: a kernel-verified sender per message, plus inert-DATA framing so a received message is read, not auto-obeyed. A scratch directory gives you neither guarantee.
Why not just let one agent's output become another agent's prompt directly?
That's the confused-deputy/injection risk agentixmesh exists to blunt. Piping one agent's raw output straight into another's prompt gives it the same authority as a direct instruction, including anything smuggled into that output. agentixmesh instead delivers messages as an inert DATA frame the receiving agent reads but never auto-executes; answering in words is fine, acting on a message's say-so is not.
Doesn't framing messages as inert data add friction compared to just prompting the other agent directly?
Some, yes, and it's deliberate. Direct prompting collapses 'received text' and 'instruction to follow' into one thing, which is exactly the confused-deputy failure mode. agentixmesh keeps them separate: the frame is unambiguously data, and the receiving agent — not the message — decides whether and how to act. That's the cost of not being trivially injectable.
How is this different from bridging two agents through Slack or a chat channel?
A chat bridge gives you a shared room where anyone holding the credentials can post as themselves — useful for humans, but it doesn't verify at the OS level which process sent a message, and it has no built-in 'this is data, not a command' framing. agentixmesh's identity guarantee is kernel-derived (fstat on the sender's own open file descriptor), and delivery defaults to inert framing rather than a live stream an agent might read as instructions.
Where does agentixmesh fit relative to AgentsWeaver and Tokonomix?
They're three layers of one family, not competitors. agentixmesh is the local, single-machine on-ramp — file-based, kernel-verified identity, one host. AgentsWeaver is the cross-machine, cryptographically-signed scale-up for when agents span hosts. Tokonomix is cross-vendor LLM consensus — routing one question to multiple models and judging the answers. Different problems, same trust-first approach.
When would I outgrow agentixmesh and need something like AgentsWeaver?
When your agent sessions stop living on one machine. agentixmesh's identity guarantee is rooted in a local kernel primitive — fstat on an open file descriptor — which has no answer for proving a message came from a different host; that requires network-level cryptographic signing, the problem AgentsWeaver targets. Multiple OS users on one machine is still agentixmesh's territory (cross-user mode), just human-gated.
Is Tokonomix a replacement for agentixmesh?
No — different job. Tokonomix answers 'is this output good?' by sending one question to multiple LLM vendors and synthesizing a judged answer. agentixmesh answers 'can I trust who sent me this message?' between agent sessions. They can be used side by side in the same workflow, but neither substitutes for the other.
Is agentixmesh a replacement for orchestration frameworks like LangGraph or CrewAI?
No — orchestration frameworks decide what an agent does next within one process or workflow; agentixmesh moves trustworthy messages between separate agent sessions or processes that don't share memory or authority. A session can run an orchestration framework internally and also send and receive over agentixmesh — they operate at different layers and largely don't overlap.
How is agentixmesh different from MCP (Model Context Protocol)?
They sit at different layers. MCP connects one model to its tools and context — the agent invokes capabilities deliberately, as its own actions. agentixmesh is the trust boundary between already-running agent sessions: the sender's OS user id is kernel-verified and the content arrives as inert data, never as an instruction the agent must follow. Adjacent, not competing — the agentixmesh vs MCP page has the full side-by-side.
Can agentixmesh and MCP run side by side?
Yes — that is the expected setup. Each session keeps its own MCP servers for capabilities, while agentixmesh carries the messages between sessions. The mesh delivers a request as data; whether the agent acts on it remains a decision inside the receiving session, under its own permissions.

Setup, limits & roadmap

Does agentixmesh require a background daemon or server process?
No daemon. Same-user delivery runs on a maildir (new/cur/held/seen folders) plus an inject hook that fires when an agent session starts or a prompt is submitted — nothing has to run continuously in the background. There's no persistent process to crash, restart, or babysit for the core same-user path.
Does agentixmesh open a network port?
No. It has no network listener of any kind — same-user messaging is plain filesystem I/O: a message is written into a maildir directory and picked up by the inject hook on the next session event. There's no socket to open, no port to firewall, nothing listening for connections.
Do I need sudo or root to use agentixmesh?
No, not for the same-user core. Mailboxes are owner-only directories (mode 0700) that a normal user account creates and reads on its own. Root only becomes relevant if you go on to provision the optional cross-user layer's shared host setup — everyday same-user messaging never touches sudo.
What does a host need to run agentixmesh?
Just one machine, a filesystem the user account can write to, Python, and a maildir living under that user's home directory. The other piece is an inject hook wired into your agent harness so incoming messages get rendered into a session's context — no exotic infrastructure beyond that.
How do I install agentixmesh?
Wire four host integration points: a Python path entry so the package is importable, CLI wrappers (like `mesh-send`) on your PATH, a skill file your agent harness loads, and an inject hook that fires on session start and prompt submit. It's open source on GitHub (github.com/TokonoMix/agentixmesh, MIT), so you clone it and run the install steps yourself.
Is agentixmesh self-hostable?
Yes — it's only self-hosted. There is no hosted service or SaaS backend; agentixmesh is local files (a maildir) plus a hook you install into your own agent harness on your own machine. You control the transport end to end, and no message data leaves your host.
What happens if I never install the inject hook?
Messages just sit undelivered in the maildir. The hook is what renders a new message into an agent session's context at session start or prompt submit — without it, sending still works and messages queue up, but nothing surfaces them to the receiving agent until the hook runs.
Is agentixmesh limited to a single machine?
Yes — today agentixmesh only delivers between agent sessions on the same machine. There is no network transport, so it cannot route a message to a session running on a different host. Cross-machine delivery is a real, distinct need it doesn't currently address.
Will agentixmesh support cross-machine delivery?
It's on the roadmap, not shipped today. agentixmesh's core is single-machine only, with no network transport built in. Cross-machine, cryptographically-signed delivery at scale is the explicit job of a sibling project, AgentsWeaver — agentixmesh is positioned as the local, single-machine on-ramp, not the scaled-up cross-network transport.
What's the "higher-authority layer" on the roadmap?
Leader-gate co-approval, group roles, and consent-gated leader-read monitoring — mechanisms for a team lead to co-approve or observe agent traffic with consent. They exist in design/prototype form today but are not shipped and are explicitly not advertised as production security; treat them as roadmap, not a hardened guarantee.
What license is agentixmesh under?
MIT. The code is public on GitHub at github.com/TokonoMix/agentixmesh — read it, fork it, self-host it, or modify it without asking permission. There's no separate paid tier or closed core hiding behind the public repo; what you see is what runs.
Is agentixmesh actively maintained?
It's developed as an open source project with full commit history public on GitHub, so you can check activity yourself before depending on it. There's no formal support SLA — as with any MIT-licensed project, adopting it means taking on your own operational ownership of the fork you run.
What does agentixmesh deliberately NOT do?
It doesn't run as a network service, doesn't require sudo for same-user use, doesn't auto-act on a message's contents, and doesn't claim to stop prompt injection outright. It delivers messages as inert data for an agent to read and decide about — the mesh itself never executes an instruction found inside a message body.

Talk to us

Every conversation starts in the chat — tell us what you're here for and the assistant takes it from there.