Customer support CLI: run tickets and AI agents from the terminal

What people picture when they search "customer support CLI"

I build integrations at eesel, so I spend a lot of time in helpdesk APIs and other people's terminals. The request I hear most from developer-leaning support teams is some version of "I just want to manage this from the command line." Usually they are picturing a single binary: support resolve #4821, and the ticket closes with a correct answer.

That mental model quietly bundles two very different things. One is operating on tickets: bulk-tagging, reassigning, exporting, closing stale threads, mass-updating a custom field after a migration. The other is resolving tickets: reading the customer's problem, finding the right answer, deciding whether to escalate, and writing a reply that is safe to send. The first is a scripting job. The second is an AI job, and no CLI ships it for you.

It helps to see the terminal as three stacked layers, each with more autonomy than the one below it.

Most of the confusion in this space comes from expecting the bottom layer to do the top layer's work. So let me walk each one honestly, with the real commands and the real limits.

Layer 1: the helpdesk CLI is a developer tool, not a ticket console

Start with the most literal reading. Does your helpdesk ship a command line tool? Zendesk does, and it is the closest thing to an official "customer support CLI" on the market. It is called zcli, it installs with yarn global add @zendesk/zcli, and it is built on oclif (the same framework behind the Heroku and Salesforce CLIs).

Here is the part that surprises people. Its command groups are apps, themes, connectors, profiles, login, and logout. That is the whole surface. You can create and package a Zendesk App, upload a Guide theme, wire an early-access connector, and manage OAuth profiles. What you cannot do is touch a ticket. There is no zcli tickets:create, no zcli tickets:reply, no zcli tickets:close. The tool exists to help developers build things on top of Zendesk, not to run the support queue from a shell.

That is not a knock on zcli. It is a well-maintained tool doing exactly its job (recent commits are moving auth from API tokens to browser-based OAuth, which is the right direction). It is just a different job than the one most "customer support CLI" searchers have in mind. If you install it hoping to close tickets and find only an app scaffolder, that gap is the whole reason this post exists. It is the same gap that shows up when people search for a customer support agent API and get a model endpoint instead of an agent.

Freshdesk, Gorgias, Help Scout, and Front do not ship a first-party CLI at all. So for every helpdesk except Zendesk, and for Zendesk itself once you want to touch tickets, you drop down to the next layer.

Layer 2: curl and the REST API is the real terminal path

This is where the actual work happens. Every serious helpdesk exposes its tickets over a REST API, and a REST API is something curl, bash, and jq can drive all day. When someone automates support "from the command line," this is almost always what they built, even if they imagined a purpose-made CLI.

A create-ticket call against Zendesk is a plain HTTP POST:

curl https://yourco.zendesk.com/api/v2/tickets.json \
  -u "$ZD_EMAIL/token:$ZD_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"ticket":{"subject":"Refund not received","comment":{"body":"Order #DL-4821"}}}'

The same shape covers updating a ticket, listing with pagination, adding comments, and exporting. Wrap a few of these in shell functions and you effectively have your own customer support CLI, tuned to exactly the operations you run. The same is true on the other platforms: Freshdesk has a documented ticket API, Gorgias offers both a REST and GraphQL API, and Help Scout has its own Mailbox API.

The catch is everything the happy-path snippet leaves out. You have to handle authentication and scopes, rate limits (helpdesk APIs return HTTP 429 with a Retry-After header, and the ceilings are per-minute and tiered by plan), idempotency so a retried POST does not create duplicate tickets, and error codes when a field validation fails at 2am. Freshdesk publishes its own rate-limit tiers and Gorgias its own API v2 limits, and they are all different, so a script that works against one helpdesk is not portable to the next.

None of this is hard, exactly. It is just real software you now maintain. And critically, it still only gets you the operating on tickets half. A curl script can close ticket #4821. It has no idea whether closing it was the right call. If you want the API to be the whole product, that is the headless customer support route, and it comes with the same 90% attached.

Layer 3: MCP turns the terminal into an AI agent surface

Here is the genuinely new layer, and the reason a "customer support CLI" feels more real in 2026 than it did two years ago. The Model Context Protocol (MCP) is a standard way to expose a tool's actions to an AI agent. Instead of hand-wiring every endpoint, you connect an MCP server once, and an agent running in your terminal (Claude Code, or any MCP client) can list tickets, read a thread, and post a reply as tool calls.

Front ships an official MCP server for free. Zendesk and Gorgias both let you connect an AI model through MCP-style connectors, and vendors like Freshworks have published an MCP gateway of their own. For a developer, this is the closest the ecosystem gets to typing a plain-language command and having support work happen: you ask the agent to "close every ticket tagged spam from last week," and it makes the API calls. It is the same idea behind wiring an AI helpdesk API, just driven from a terminal agent instead of a backend service.

MCP is a real step forward, and if you are already living in a terminal agent it is worth wiring up. But notice what it does and does not solve. MCP standardizes the connection, the way Claude Code MCP tools standardize how the agent reaches your systems. It does nothing about the agent's judgment. The model still needs to know your product, your refund policy, and your escalation rules, and it will confidently guess when it does not. Whether it should send that reply, and what it does when it is unsure, is entirely on you. Which brings us to the layer no CLI, curl script, or MCP server hands you.

The part no CLI gives you: resolution intelligence

Type resolve ticket #4821 and imagine everything that command has to be true for the resolution to be correct and safe. That is the work that actually matters, and it lives above the API entirely.

Every one of those is its own subsystem: keeping the agent's knowledge in sync with your help center and past tickets, tracking conversation state across a multi-message thread, guardrails so it answers only from approved sources and not the model's general training, escalation rules for when it should hand off to a human, and a way to test the whole thing before it touches a live customer. We have spent the last three-plus years putting AI agents on live support queues, and the lesson that stuck is that the model call is roughly 10% of the work. The other 90% is this list, and it never ships in a CLI.

I hear the same realization on sales calls. One CX lead at a US healthcare platform, running around 500 Zendesk tickets a month, had already tried the native tooling and told us they found it "largely inadequate and overpriced," so they were looking to bring real automation to the whole process. That is the pattern: teams reach for the terminal because the packaged AI let them down, then discover the terminal only hands them the plumbing, not the intelligence. A technical evaluator at a hardware company put the real requirement plainly on another call: they needed assurance the AI answers only from approved knowledge, never from the open web. That is a guardrail, and a guardrail is not something you apt install.

This is the honest limit of the whole "customer support CLI" dream. The command line is a fantastic control surface for the parts that are deterministic. Resolution is not deterministic, and pretending a script makes it so is how you end up with a confident bot giving wrong answers at scale.

Script it yourself vs connect a teammate

So you have two real paths once you get past the ops-and-config layer: build the resolution engine on top of a raw model API, or connect a ready-made teammate that ships it. Here is how they actually compare.

The cost line is the one that decides most cases. A model API bills you per token on every message, retry, and retrieved chunk, whether or not the ticket got solved. A teammate that bills per resolved ticket ties the cost to the outcome you actually wanted. Neither is universally right, but if you do not have engineers who want to own an AI pipeline forever, the maintenance column is where the "build it in the terminal" plan quietly falls apart.

Which path actually fits you

There is no single answer, but there is a clean way to choose, and it comes down to what you actually want the terminal to do.

• You want bulk edits, exports, and config. Stay in the terminal. Use zcli for Zendesk app and theme work, and curl plus jq for ticket operations. This is the CLI's sweet spot and you should not overthink it.
• You want an AI agent you fully control. Wire an MCP server into your terminal agent and be ready to own the knowledge, guardrails, and testing yourself. Good if you have the engineering appetite and a real reason to keep it in-house.
• You want resolved tickets without building an engine. Connect a teammate to the helpdesk you already run. You skip the 90% and still keep a real control surface for the deterministic parts.

Most teams I work with land on a mix: curl scripts for the ops nobody should pay an AI to do, and a teammate for the resolution work that a script was never going to handle safely. That is not a compromise, it is just matching each layer to the job it is good at, the same way you would pick between AI and rule-based automation for any support workflow.

Try eesel for the resolution layer

If the layer you are missing is the resolution engine, that is exactly what eesel ships. It is an AI teammate that plugs into the helpdesk you already run (Zendesk, Freshdesk, Gorgias, Help Scout, Front, and more), trains on your past tickets and help center, and joins the queue as a support teammate rather than a stack you have to assemble.

The differentiator that matters for a developer who has seen bots go wrong: you can simulate the agent on your historical tickets before it ever touches a live customer, so you see how it would have handled real conversations first. Every action (reply, tag, escalate) is off by default and can be set to full automation or approval-only, so you connect everything and test privately, then flip the parts you trust. It is self-serve, bills per ticket handled with no per-seat fee, and goes live in minutes. You keep your curl scripts for the ops; eesel takes the resolution work off your plate.