Skip to main content
Glama
README.md
# 2Bot

**2Bot** is a FastMCP server that lets ChatGPT (or any MCP client) call your local Codex CLI through a controlled MCP tool.

- MCP server name is fixed to **`2Bot`**.
- Local mode uses **stdio**.
- Remote mode uses **HTTP (Streamable HTTP)** for ChatGPT-compatible deployments.

## What 2Bot does

2Bot exposes a single typed tool, `run_codex_prompt`, which runs `codex exec --json -` safely:

- no `shell=True`
- prompt passed via stdin
- timeout handling
- working-directory validation and allowlist support
- JSON-serializable structured output

## Installation

```bash
python -m venv .venv
source .venv/bin/activate
pip install -e .
```

For tests:

```bash
pip install -e .[dev]
pytest
```

## Configuration

2Bot is environment-driven.

| Variable | Default | Description |
|---|---|---|
| `TWOBOT_TRANSPORT` | `stdio` | `stdio` or `http` |
| `TWOBOT_HOST` | `127.0.0.1` | HTTP bind host |
| `TWOBOT_PORT` | `9000` | HTTP bind port |
| `TWOBOT_BASE_URL` | unset | Optional public HTTPS URL for docs/ops |
| `TWOBOT_LOG_LEVEL` | `INFO` | Logging level |
| `TWOBOT_ENABLE_NO_AUTH` | `true` | Enable no-auth mode for initial ChatGPT testing |
| `CODEX_ALLOWED_ROOTS` | unset | Optional cwd allowlist (`:`-separated on macOS/Linux) |

> Authentication note: for first connection tests, use **no auth**. For production, prefer standards-based MCP-compatible auth in front of or integrated with this service.

## Local mode (stdio)

Run with stdio (default):

```bash
2bot-mcp
# or
python -m twobot_codex_mcp.server
```

You can also force stdio:

```bash
TWOBOT_TRANSPORT=stdio 2bot-mcp
```

## Remote mode (HTTP / Streamable HTTP)

Run HTTP mode locally on loopback:

```bash
TWOBOT_TRANSPORT=http TWOBOT_HOST=127.0.0.1 TWOBOT_PORT=9000 2bot-mcp
```

Or with explicit CLI flags:

```bash
2bot-mcp --transport http --host 127.0.0.1 --port 9000
```

### Expose via HTTPS for ChatGPT

ChatGPT must reach a public HTTPS URL. Typical setup:

1. Run 2Bot in HTTP mode on `127.0.0.1:9000`.
2. Put a reverse proxy or tunnel in front (Nginx, Caddy, Cloudflare Tunnel, etc.).
3. Publish a TLS endpoint like `https://mcp.example.com` forwarding to `http://127.0.0.1:9000`.
4. Configure ChatGPT custom MCP connection to that public URL.

## ChatGPT connection notes

ChatGPT connects to the **remote HTTPS MCP endpoint**, not to stdio.

High-level flow:

1. Start 2Bot in HTTP mode.
2. Expose the endpoint at a public HTTPS URL.
3. Create/connect the custom MCP app in ChatGPT pointing at that URL.

Use URL pattern:

- **`https://<your-public-hostname>/`** (or the exact path your reverse proxy maps to the FastMCP HTTP app)

## Security notes (important)

Exposing a tool that can execute local Codex workflows is sensitive.

Recommendations:

- Restrict `CODEX_ALLOWED_ROOTS` to minimal directories.
- Keep conservative defaults (`sandbox=read-only`, `allow_edits=false`).
- Avoid `danger-full-access` unless absolutely necessary and trusted.
- Prefer private deployments (VPN, private network, authenticated gateway).
- Do not expose an unrestricted instance on the public internet casually.

## Example deployment notes

### 1) Local-only HTTP bind

```bash
TWOBOT_TRANSPORT=http TWOBOT_HOST=127.0.0.1 TWOBOT_PORT=9000 2bot-mcp
```

### 2) Reverse proxy / tunnel

- Proxy `https://mcp.example.com` -> `http://127.0.0.1:9000`
- Keep TLS at the edge
- Keep 2Bot private behind the proxy where possible

### 3) Keep stdio mode for local MCP clients

```bash
TWOBOT_TRANSPORT=stdio 2bot-mcp
```

## Tool reference: `run_codex_prompt`

Parameters:

- `prompt: str`
- `cwd: str | None = None`
- `model: str | None = None`
- `profile: str | None = None`
- `sandbox: "read-only" | "workspace-write" | "danger-full-access" = "read-only"`
- `approval_policy: "untrusted" | "on-request" | "never" | None = None`
- `allow_edits: bool = False`
- `skip_git_repo_check: bool = False`
- `add_dirs: list[str] | None = None`
- `timeout_sec: int = 1800`
- `ephemeral: bool = True`
- `include_event_log: bool = False`

Behavior is preserved from local mode while adding transport/config flexibility.

TDQS

B3.4/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is zero ambiguity—no other tools exist to confuse with run_codex_prompt. The tool's purpose is distinct by default.

Naming Consistency5/5

The single tool name 'run_codex_prompt' follows a clean verb_noun pattern, making it clear and predictable. With only one tool, consistency is inherently maintained.

Tool Count2/5

A single tool is extremely thin for an MCP server, even for a narrow purpose. While it might serve a specific need, it feels like a minimal wrapper rather than a coherent tool set, earning a low score.

Completeness3/5

The tool covers the basic action of running a codex prompt, but the surface is incomplete—no ability to list past runs, check status, cancel, or configure the CLI. For the implied domain, notable operations are missing.