Skip to main content

Other MCP Clients

Connect Cursor, Goose, aider, or any other MCP client to TermFlow. These work because they speak the same protocol as the first-class clients — but TermFlow does not generate a paste-ready config for them, so you wire them up by hand.

The one thing you need

TermFlow's MCP server is a streamable-HTTP endpoint. Any MCP client that can connect to a streamable-HTTP (a.k.a. "HTTP" / "http-stream") server can drive TermFlow by pointing at a single URL:

http://127.0.0.1:42032/mcp

That is the default production MCP port (42032). If you changed the MCP port in Settings → Connections, substitute your value. Once connected, the client sees the same seven MCP toolslist_terminals, create_terminal, execute_command, and the rest — that Claude Code, Codex CLI, and Gemini CLI use.

Which clients are "first-class"?

Only Claude Code, Codex CLI, and Gemini CLI have copy-paste configs generated by the in-app Connect an AI agent modal (Settings → Connections). Everything on this page is set up manually. See the dedicated pages for the first-class clients: Claude Code, Codex CLI, Gemini CLI.

An honest note: These clients are supported in the sense that they speak MCP and TermFlow speaks MCP — nothing more, nothing less. TermFlow does not generate their config, does not ship client-specific presets, and cannot promise that a given client's streamable-HTTP support is complete or bug-free. If a client can talk to any remote MCP server over HTTP, it can talk to TermFlow. If it only supports stdio-based MCP servers (like aider), you need a bridge — see below.

The values to enter

However your client stores MCP server settings, these are the values it needs. Field names differ between clients (some call the URL url, others httpUrl; some nest headers, some don't), so map these into whatever shape your client expects.

SettingValueWhen needed
Transporthttp / streamable-HTTPAlways
Server URLhttp://127.0.0.1:42032/mcpAlways
Authorization headerBearer <token>Only when TermFlow is exposed on the LAN
X-Termflow-Terminal-Id header<your terminal id>Optional — enables get_my_terminal / the "me" shorthand

A generic config, in the shape most MCP clients use, looks like this — adapt the key names to your specific client:

{
"mcpServers": {
"auto-terminal": {
"type": "http",
"url": "http://127.0.0.1:42032/mcp"
}
}
}

The server key auto-terminal is a label you choose; using auto-terminal keeps it consistent with the first-class clients, but any name works.

Generic setup steps

  1. Start TermFlow and confirm the MCP server is healthy. In Settings → Connections, the health dot should read healthy. A conflict state means another instance owns the port.
  2. Open your client's MCP configuration — a settings UI or a config file, depending on the client.
  3. Add an HTTP / streamable-HTTP MCP server and set its URL to http://127.0.0.1:42032/mcp.
  4. Add the Authorization header only if you exposed TermFlow on the LAN (see the next section). On the default localhost setup, leave it out.
  5. Reload the client and confirm it lists TermFlow's tools. A quick smoke test is asking the agent to run list_terminals.

Where the Bearer token goes

By default, TermFlow binds to 127.0.0.1 and every endpoint is unauthenticated. That is safe precisely because the server is only reachable from your own machine — no token is required, and you can omit the Authorization header entirely.

The moment you turn on "Expose on local network" in Settings → Connections, TermFlow binds to 0.0.0.0 and starts enforcing a bearer token on every request. From then on, your client must send:

Authorization: Bearer <token>

The <token> is the auth token shown in Settings → Connections — reveal and copy it there (you can also rotate it). Put it wherever your client stores per-server request headers. In the generic config above, that means adding a headers block:

{
"mcpServers": {
"auto-terminal": {
"type": "http",
"url": "http://192.168.1.50:42032/mcp",
"headers": {
"Authorization": "Bearer <token>"
}
}
}
}

When exposing on the LAN, also swap 127.0.0.1 for the machine's LAN IP — Settings → Connections lists the per-interface addresses next to the exposure toggle.

Use the token from Settings → Connections

The bearer token is the config authToken displayed in Settings → Connections. That is the only credential the auth gate checks. Do not use any other endpoint or minting flow to obtain a token — see Local API and auth for the full model.

Optional: the identity header

If you want the agent to be able to resolve its own terminal — via get_my_terminal or the "me" shorthand accepted by every tool — send the X-Termflow-Terminal-Id header set to the terminal's id. Terminals launched inside TermFlow expose this id to their child process as the TERMFLOW_TERMINAL_ID environment variable. Not every client can expand an environment variable into a header value; if yours can't, either set the header to a literal id or simply skip it and pass explicit terminal ids to each tool call.

aider needs a wrapper

aider does not connect to remote HTTP MCP servers directly. To use it with TermFlow, run an MCP wrapper — a small bridge that exposes TermFlow's streamable-HTTP endpoint (http://127.0.0.1:42032/mcp) to aider in the form aider expects. Point the wrapper at the same URL and, if exposed on the LAN, give it the same Authorization: Bearer <token> header. Everything else on this page applies unchanged.

An honest note: TermFlow does not ship or bundle an aider wrapper, and cannot recommend a specific one. Any MCP bridge that forwards to a streamable-HTTP server will do. This is inherently a bring-your-own-glue setup.

If tools don't show up

SymptomLikely causeFix
Client can't reach the serverWrong port, or TermFlow not runningConfirm the MCP port in Settings → Connections and that the health dot is healthy
401 / unauthorizedExposed on LAN without a tokenAdd Authorization: Bearer <token> using the token from Settings → Connections
Connects but no toolsClient used a stdio transport, or a non-MCP HTTP modeEnsure the client is set to streamable-HTTP and the URL ends in /mcp
get_my_terminal failsNo identity header sentAdd X-Termflow-Terminal-Id, or pass explicit terminal ids
Health shows conflictAnother instance owns the portStop the other instance or change the port

Next steps