codex-cli-mcp-slim 0.1.0__tar.gz → 0.1.2__tar.gz

{codex_cli_mcp_slim-0.1.0/src/codex_cli_mcp_slim.egg-info → codex_cli_mcp_slim-0.1.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: codex-cli-mcp-slim
-Version: 0.1.0
+Version: 0.1.2
 Summary: A thin, auditable MCP server wrapping the Codex CLI (codex exec). Same tools as the deprecated `codex mcp-server`; forward-compatible with future CLI flags via extra_args passthrough.
 Author-email: tksfjt1024 <tksfjt1024@gmail.com>
 License: MIT
@@ -171,7 +171,9 @@ After:
 Parameter names differ from the old server where `codex exec` names the flag
 differently: `cwd` is now `cd` (the `-C/--cd` flag), and `codex-reply` takes
 `thread_id` instead of `threadId`. The result's `structuredContent` field keeps
-the shape the old server returned, `{"threadId": ..., "content": ...}`.
+the shape the old server returned, `{"threadId": ..., "content": ...}`. It
+gains an `ignoredParameters` key only when the server's own flags overrode a
+per-call parameter (see [Server-level flags](#server-level-flags)).
 
 ### Other MCP clients
 
@@ -207,11 +209,25 @@ in reasoning effort look like this:
 
 A call to `codex-high` runs
 `codex exec -c model_reasoning_effort=high [per-call flags] --json -`. Per-call
-flags come after the server-level ones, and `-c` may repeat with the last one
-winning, so a per-call `config` entry overrides a server-level `-c`. Single-value
-flags such as `-m` and `-C` may not repeat: `codex` rejects the second one, and
-the tool result carries that error. Keep server-level flags and per-call
-parameters disjoint for those.
+flags come after the server-level ones. `-c` and `--add-dir` may repeat. For
+`-c` the last one wins, so a per-call `config` entry overrides a server-level
+`-c`.
+
+The other typed flags (`-C`, `-m`, `--sandbox`, `-p`, `--ephemeral`,
+`--skip-git-repo-check`) may appear only once: `codex` exits with "cannot be used
+multiple times" on a second one. When the server's command line already sets one
+of them, in any spelling (for example `-C DIR`, `-CDIR`, `--cd=DIR`), the
+server-level value wins. A token that is another flag's value (the `-m` in
+`-c -m`) or that comes after `--` does not count as setting a flag. The `codex`
+tool leaves the matching per-call parameter (`cd`, `model`, `sandbox`,
+`profile`, `ephemeral`, `skip_git_repo_check`) out of the command and names it
+in the result together with the server-level value used instead: in the text
+after the `[codex]` line (`cd="/other"; this server runs with -C /srv`) and in
+`structuredContent.ignoredParameters`. Its schema tells the caller which
+parameters the server already sets, and to what. `codex-reply` keeps such
+parameters, because after `resume` they are the subcommand's own flags and
+`codex` accepts them there. `extra_args` is passed through unchecked, so a flag
+repeated through it still fails with `codex`'s own error.
 
 ## Tool: `codex`
 
@@ -226,7 +242,10 @@ The tool returns that final message followed by one metadata line:
 ```
 
 `thread_id` and `status` are always present; the token fields appear when the
-run reported them. `isError` is the flag on an MCP tool result that tells the
+run reported them. A per-call parameter that a server-level flag overrode is
+named after this line, with the value used instead (see
+[Server-level flags](#server-level-flags)).
+`isError` is the flag on an MCP tool result that tells the
 client a call failed. This server sets it when `codex` exited non-zero, when the
 subprocess timed out, and when the turn itself failed. The last case matters
 because `codex exec` exits 0 after a failure inside the model API; the tool
@@ -309,6 +328,31 @@ buffered output and reap the process, so the effective ceiling is
 `timeout_seconds + 20`. A timed-out call is flagged `isError` and carries
 whatever `codex` had printed so far.
 
+An MCP client may give up on a call that has sent neither a response nor a
+progress notification for a while. Claude Code 2.1.318 does so after 1800
+seconds by default for a stdio server ("sent no response or progress for
+1800s"), and a long `codex` turn can take longer than that. While `codex` runs,
+the server therefore sends a `notifications/progress` message every 60 seconds,
+so the call lasts until `codex` finishes or `timeout_seconds` runs out. A client
+gets these only when it sent a `progressToken` with the call, as Claude Code
+does; a client that gives up after less than 60 seconds without progress is not
+covered. With the default `timeout_seconds` of 1800 the call still ends after
+about 30 minutes, at the server's own timeout, so to let `codex` run longer,
+raise `timeout_seconds` (30 to 3600 per call) or `$CODEX_CLI_MCP_SLIM_TIMEOUT`,
+which sets the default. In the notification's `params`, `progress` counts the
+notifications sent so far and `message` says how long `codex` has been running:
+
+```json
+{
+  "jsonrpc": "2.0",
+  "method": "notifications/progress",
+  "params": {"progressToken": 7, "progress": 2, "message": "codex running for 120s"}
+}
+```
+
+If sending a notification raises an error, the server logs it to stderr and the
+call and its result are unaffected.
+
 ## Forward-compatibility example
 
 If a future `codex exec` release adds a new flag (say `--super-mode`), use it

{codex_cli_mcp_slim-0.1.0 → codex_cli_mcp_slim-0.1.2}/README.md

@@ -136,7 +136,9 @@ After:
 Parameter names differ from the old server where `codex exec` names the flag
 differently: `cwd` is now `cd` (the `-C/--cd` flag), and `codex-reply` takes
 `thread_id` instead of `threadId`. The result's `structuredContent` field keeps
-the shape the old server returned, `{"threadId": ..., "content": ...}`.
+the shape the old server returned, `{"threadId": ..., "content": ...}`. It
+gains an `ignoredParameters` key only when the server's own flags overrode a
+per-call parameter (see [Server-level flags](#server-level-flags)).
 
 ### Other MCP clients
 
@@ -172,11 +174,25 @@ in reasoning effort look like this:
 
 A call to `codex-high` runs
 `codex exec -c model_reasoning_effort=high [per-call flags] --json -`. Per-call
-flags come after the server-level ones, and `-c` may repeat with the last one
-winning, so a per-call `config` entry overrides a server-level `-c`. Single-value
-flags such as `-m` and `-C` may not repeat: `codex` rejects the second one, and
-the tool result carries that error. Keep server-level flags and per-call
-parameters disjoint for those.
+flags come after the server-level ones. `-c` and `--add-dir` may repeat. For
+`-c` the last one wins, so a per-call `config` entry overrides a server-level
+`-c`.
+
+The other typed flags (`-C`, `-m`, `--sandbox`, `-p`, `--ephemeral`,
+`--skip-git-repo-check`) may appear only once: `codex` exits with "cannot be used
+multiple times" on a second one. When the server's command line already sets one
+of them, in any spelling (for example `-C DIR`, `-CDIR`, `--cd=DIR`), the
+server-level value wins. A token that is another flag's value (the `-m` in
+`-c -m`) or that comes after `--` does not count as setting a flag. The `codex`
+tool leaves the matching per-call parameter (`cd`, `model`, `sandbox`,
+`profile`, `ephemeral`, `skip_git_repo_check`) out of the command and names it
+in the result together with the server-level value used instead: in the text
+after the `[codex]` line (`cd="/other"; this server runs with -C /srv`) and in
+`structuredContent.ignoredParameters`. Its schema tells the caller which
+parameters the server already sets, and to what. `codex-reply` keeps such
+parameters, because after `resume` they are the subcommand's own flags and
+`codex` accepts them there. `extra_args` is passed through unchecked, so a flag
+repeated through it still fails with `codex`'s own error.
 
 ## Tool: `codex`
 
@@ -191,7 +207,10 @@ The tool returns that final message followed by one metadata line:
 ```
 
 `thread_id` and `status` are always present; the token fields appear when the
-run reported them. `isError` is the flag on an MCP tool result that tells the
+run reported them. A per-call parameter that a server-level flag overrode is
+named after this line, with the value used instead (see
+[Server-level flags](#server-level-flags)).
+`isError` is the flag on an MCP tool result that tells the
 client a call failed. This server sets it when `codex` exited non-zero, when the
 subprocess timed out, and when the turn itself failed. The last case matters
 because `codex exec` exits 0 after a failure inside the model API; the tool
@@ -274,6 +293,31 @@ buffered output and reap the process, so the effective ceiling is
 `timeout_seconds + 20`. A timed-out call is flagged `isError` and carries
 whatever `codex` had printed so far.
 
+An MCP client may give up on a call that has sent neither a response nor a
+progress notification for a while. Claude Code 2.1.318 does so after 1800
+seconds by default for a stdio server ("sent no response or progress for
+1800s"), and a long `codex` turn can take longer than that. While `codex` runs,
+the server therefore sends a `notifications/progress` message every 60 seconds,
+so the call lasts until `codex` finishes or `timeout_seconds` runs out. A client
+gets these only when it sent a `progressToken` with the call, as Claude Code
+does; a client that gives up after less than 60 seconds without progress is not
+covered. With the default `timeout_seconds` of 1800 the call still ends after
+about 30 minutes, at the server's own timeout, so to let `codex` run longer,
+raise `timeout_seconds` (30 to 3600 per call) or `$CODEX_CLI_MCP_SLIM_TIMEOUT`,
+which sets the default. In the notification's `params`, `progress` counts the
+notifications sent so far and `message` says how long `codex` has been running:
+
+```json
+{
+  "jsonrpc": "2.0",
+  "method": "notifications/progress",
+  "params": {"progressToken": 7, "progress": 2, "message": "codex running for 120s"}
+}
+```
+
+If sending a notification raises an error, the server logs it to stderr and the
+call and its result are unaffected.
+
 ## Forward-compatibility example
 
 If a future `codex exec` release adds a new flag (say `--super-mode`), use it

{codex_cli_mcp_slim-0.1.0 → codex_cli_mcp_slim-0.1.2}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "codex-cli-mcp-slim"
-version = "0.1.0"
+version = "0.1.2"
 description = "A thin, auditable MCP server wrapping the Codex CLI (codex exec). Same tools as the deprecated `codex mcp-server`; forward-compatible with future CLI flags via extra_args passthrough."
 readme = "README.md"
 requires-python = ">=3.10"

{codex_cli_mcp_slim-0.1.0 → codex_cli_mcp_slim-0.1.2}/src/codex_cli_mcp_slim/server.py

@@ -20,10 +20,12 @@ import contextlib
 import json
 import logging
 import os
+import shlex
 import signal
 import sys
+from collections.abc import Awaitable, Callable
 from importlib.metadata import version as _pkg_version
-from typing import Any
+from typing import Any, NamedTuple
 
 from mcp.server import Server, ServerRequestContext
 from mcp.server.stdio import stdio_server
@@ -41,6 +43,16 @@ logger = logging.getLogger("codex_cli_mcp_slim")
 CODEX_CMD = os.environ.get("CODEX_CMD", "codex")
 DEFAULT_TIMEOUT = int(os.environ.get("CODEX_CLI_MCP_SLIM_TIMEOUT", "1800"))
 
+# Seconds between the progress notifications _run_codex sends while codex runs. An MCP client
+# may abort a call that sends neither a response nor progress for a while (Claude Code does
+# so after 1800s by default: "sent no response or progress for 1800s"), and a long codex turn
+# outlasts that; the notifications are what keeps such a call alive.
+PROGRESS_INTERVAL = 60
+
+# ServerSession.report_progress, or anything called the same way. It does nothing when the
+# client sent no progress token with the call.
+_ReportProgress = Callable[..., Awaitable[None]]
+
 _PKG_NAME = "codex-cli-mcp-slim"
 
 # Flags placed right after `codex exec` on every invocation. main() fills this from the
@@ -49,12 +61,89 @@ _PKG_NAME = "codex-cli-mcp-slim"
 #
 #     uvx codex-cli-mcp-slim -c model_reasoning_effort=high -C /srv/scratch
 #
-# `-c` may repeat and the last one wins, so a per-call `config` can override a server-level
-# `-c`. Single-value flags such as `-m` and `-C` may not repeat: codex rejects the second
-# one, and the tool result carries that error. Keep server-level flags and per-call
-# parameters disjoint for those.
+# `-c` and `--add-dir` may repeat (for `-c` the last one wins), so a per-call `config` can
+# override a server-level `-c`. The flags in _SINGLE_USE_FLAGS may not: see there.
 SERVER_ARGS: list[str] = []
 
+# Per-call parameters whose flag codex accepts only once, with every spelling of that flag.
+# A second occurrence makes `codex exec` exit 2 with "cannot be used multiple times", so when
+# the server's own command line already carries one of these flags, the per-call parameter
+# is left out of argv and the server-level value is used: whoever started the server fixed
+# that configuration on purpose.
+_SINGLE_USE_FLAGS: dict[str, tuple[str, ...]] = {
+    "cd": ("-C", "--cd"),
+    "model": ("-m", "--model"),
+    "sandbox": ("-s", "--sandbox"),
+    "profile": ("-p", "--profile"),
+    "ephemeral": ("--ephemeral",),
+    "skip_git_repo_check": ("--skip-git-repo-check",),
+}
+
+
+# The `codex exec` options (codex-cli 0.159.2) that take the next token as their value, so
+# _params_set_by reads that token as a value and never as a flag of its own.
+_VALUE_FLAGS = frozenset(
+    {
+        *("-c", "--config", "--enable", "--disable", "-i", "--image"),
+        *("-m", "--model", "--local-provider", "-p", "--profile", "-s", "--sandbox"),
+        *("-C", "--cd", "--add-dir", "--thread-source", "--output-schema", "--color"),
+        *("-o", "--output-last-message"),
+    }
+)
+
+
+class _ServerSetting(NamedTuple):
+    """How the server's own command line sets one of the _SINGLE_USE_FLAGS parameters."""
+
+    value: str | bool  # the flag's value, or True for a flag without one
+    written: str  # the flag as that command line spells it, for example `-C /srv`
+
+
+def _params_set_by(server_args: list[str]) -> dict[str, _ServerSetting]:
+    """The _SINGLE_USE_FLAGS parameters whose flag already appears in `server_args`.
+
+    A flag counts in every form codex parses as that flag: `--cd DIR`, `--cd=DIR`, `-C DIR`
+    and the attached short forms `-CDIR` and `-C=DIR`. Short flags are case-sensitive, so the
+    repeatable `-c` is not mistaken for `-C`. The token after a _VALUE_FLAGS option is its
+    value (`-m` in `-c -m` is not the model flag), and nothing after `--` is a flag.
+    """
+    held: dict[str, _ServerSetting] = {}
+    tokens = iter(server_args)
+    for token in tokens:
+        if token == "--":
+            break
+        if token in _VALUE_FLAGS:
+            value = next(tokens, None)
+            if value is None:
+                break
+            param = next((p for p, flags in _SINGLE_USE_FLAGS.items() if token in flags), None)
+            if param is not None:
+                held.setdefault(param, _ServerSetting(value, shlex.join([token, value])))
+            continue
+        for param, spellings in _SINGLE_USE_FLAGS.items():
+            for flag in spellings:
+                if token == flag:
+                    held.setdefault(param, _ServerSetting(True, token))
+                elif len(flag) == 2 and token.startswith(flag):
+                    value = token[2:].removeprefix("=")
+                    held.setdefault(param, _ServerSetting(value, shlex.quote(token)))
+                elif token.startswith(flag + "="):
+                    value = token[len(flag) + 1 :]
+                    held.setdefault(param, _ServerSetting(value, shlex.quote(token)))
+    return held
+
+
+# What SERVER_ARGS sets among the _SINGLE_USE_FLAGS parameters. _set_server_args parses it
+# once, together with SERVER_ARGS, so _build_argv, _invoke and on_list_tools read one answer.
+_SERVER_SET: dict[str, _ServerSetting] = {}
+
+
+def _set_server_args(server_args: list[str]) -> None:
+    global SERVER_ARGS, _SERVER_SET
+    SERVER_ARGS = list(server_args)
+    _SERVER_SET = _params_set_by(SERVER_ARGS)
+
+
 # The Server is built at the bottom of this file: v2 takes the handlers as constructor
 # arguments, so they must already be defined by the time it is constructed.
 
@@ -73,8 +162,11 @@ def _build_argv(
     extra_args: list[str] | None = None,
     server_args: list[str] | None = None,
 ) -> list[str]:
-    argv: list[str] = [CODEX_CMD, "exec"]
-    argv += SERVER_ARGS if server_args is None else server_args
+    if server_args is None:
+        server_args, server_set = SERVER_ARGS, _SERVER_SET
+    else:
+        server_set = _params_set_by(server_args)
+    argv: list[str] = [CODEX_CMD, "exec", *server_args]
     if thread_id:
         # `codex exec resume <id>` is a subcommand: it has to come before the per-call flags,
         # and it accepts only a subset of them (the `codex-reply` schema advertises just that
@@ -82,21 +174,25 @@ def _build_argv(
         # `exec` options there, so a server pinned to a working directory keeps that
         # directory for replies as well.
         argv += ["resume", thread_id]
-    if cd:
+    # Per-call flags after `resume` are the subcommand's own, and codex accepts them there
+    # even when the same flag sits among the server-level ones, so only a plain `exec` call
+    # leaves out what the server already sets.
+    held = {} if thread_id else server_set
+    if cd and "cd" not in held:
         argv += ["-C", cd]
-    if model:
+    if model and "model" not in held:
         argv += ["-m", model]
     for item in config or []:
         argv += ["-c", item]  # repeatable flag: one -c per key=value
-    if sandbox:
+    if sandbox and "sandbox" not in held:
         argv += ["--sandbox", sandbox]
     for d in add_dir or []:
         argv += ["--add-dir", d]  # repeatable flag: one --add-dir per directory
-    if profile:
+    if profile and "profile" not in held:
         argv += ["-p", profile]
-    if ephemeral:
+    if ephemeral and "ephemeral" not in held:
         argv.append("--ephemeral")
-    if skip_git_repo_check:
+    if skip_git_repo_check and "skip_git_repo_check" not in held:
         argv.append("--skip-git-repo-check")
     if extra_args:
         argv += list(extra_args)
@@ -115,6 +211,7 @@ async def _run_codex(
     prompt: str,
     timeout: int,
     env_overrides: dict[str, str] | None = None,
+    report_progress: _ReportProgress | None = None,
 ) -> dict[str, Any]:
     env = os.environ.copy()
     if env_overrides:
@@ -145,6 +242,11 @@ async def _run_codex(
 
     # shield the task so a first-wait timeout doesn't cancel the second wait below
     communicate_task = asyncio.ensure_future(proc.communicate(prompt.encode()))
+    progress_task = (
+        asyncio.ensure_future(_report_progress_every(PROGRESS_INTERVAL, report_progress))
+        if report_progress is not None
+        else None
+    )
     try:
         try:
             stdout, stderr = await asyncio.wait_for(
@@ -183,10 +285,25 @@ async def _run_codex(
         _kill_process_group(proc)
         raise
     finally:
-        if not communicate_task.done():
-            communicate_task.cancel()
-            with contextlib.suppress(Exception, asyncio.CancelledError):
-                await communicate_task
+        # The progress task ends before the result goes back, since the protocol has progress
+        # stop once the call completes; cancelling it also ends a notification stuck on a
+        # client that has stopped reading. Both tasks are cancelled before anything is
+        # awaited, and the wait is repeated until they have finished. The SDK cancels a call
+        # through an anyio cancel scope, which cancels this coroutine again at every await, so
+        # a single await here could be cut short and leave communicate() running for as long
+        # as a descendant outside the process group keeps the pipes open. A cancellation that
+        # arrives during the wait is raised once the tasks are done.
+        leftovers = {t for t in (progress_task, communicate_task) if t is not None and not t.done()}
+        for task in leftovers:
+            task.cancel()
+        interrupted: asyncio.CancelledError | None = None
+        while leftovers := {t for t in leftovers if not t.done()}:
+            try:
+                await asyncio.wait(leftovers)
+            except asyncio.CancelledError as exc:
+                interrupted = exc
+        if interrupted is not None:
+            raise interrupted
 
     return {
         "ok": proc.returncode == 0,
@@ -197,6 +314,27 @@ async def _run_codex(
     }
 
 
+async def _report_progress_every(interval: float, report_progress: _ReportProgress) -> None:
+    """Send a progress notification every `interval` seconds until cancelled.
+
+    `progress` counts the notifications, so it rises with each one as the protocol requires;
+    the message carries the time codex has been running. A notification that raises is logged
+    and the next one is still sent: it must not affect the codex run or its result. (The SDK
+    itself drops a notification on a closed transport, with a debug log and no exception.)
+    """
+    loop = asyncio.get_running_loop()
+    started = loop.time()
+    count = 0
+    while True:
+        await asyncio.sleep(interval)
+        count += 1
+        elapsed = round(loop.time() - started)
+        try:
+            await report_progress(count, message=f"codex running for {elapsed}s")
+        except Exception as exc:
+            logger.warning("progress notification failed: %s: %s", type(exc).__name__, exc)
+
+
 def _kill_process_group(proc: asyncio.subprocess.Process) -> None:
     """Kill codex's process group; a descendant that setsid/setpgid away from it is out of reach."""
     if sys.platform != "win32":
@@ -572,7 +710,12 @@ def _error_result(text: str) -> CallToolResult:
     return CallToolResult(content=[TextContent(type="text", text=f"[ERROR] {text}")], is_error=True)
 
 
-async def _invoke(arguments: dict[str, Any] | None, *, reply: bool) -> CallToolResult:
+async def _invoke(
+    arguments: dict[str, Any] | None,
+    *,
+    reply: bool,
+    report_progress: _ReportProgress | None = None,
+) -> CallToolResult:
     """The body of both tools, taking a plain dict so callers need no SDK request object."""
     args = dict(arguments or {})
 
@@ -605,14 +748,37 @@ async def _invoke(arguments: dict[str, Any] | None, *, reply: bool) -> CallToolR
         prompt=args["prompt"],
         timeout=int(args.get("timeout_seconds") or DEFAULT_TIMEOUT),
         env_overrides=args.get("env"),
+        report_progress=report_progress,
     )
     parsed = _parse_events(result.get("stdout", ""))
     text = _format_result(result)
+    # Name what _build_argv left out, and the value used instead, so a caller does not take a
+    # run in the server's directory (say) for a run in the one it asked for.
+    held = {} if reply else _SERVER_SET
+    dropped = [param for param in _SINGLE_USE_FLAGS if param in held and args.get(param)]
     structured: dict[str, Any] | None = None
     if parsed["thread_id"]:
         # The same shape the deprecated `codex mcp-server` returned, so a client that reads
         # structuredContent.threadId keeps working.
         structured = {"threadId": parsed["thread_id"], "content": _response_text(parsed)}
+    if dropped:
+        lines = [
+            f"{p}={json.dumps(args[p], ensure_ascii=False)}; "
+            f"this server runs with {held[p].written}"
+            for p in dropped
+        ]
+        logger.warning("per-call parameters ignored: %s", " | ".join(lines))
+        text += (
+            "\n\nignored, because this server's own command line already sets the flag "
+            "and codex takes it only once:\n" + "\n".join(lines)
+        )
+        # A client that reads only structuredContent learns it here.
+        structured = {
+            **(structured or {}),
+            "ignoredParameters": [
+                {"name": p, "value": args[p], "serverValue": held[p].value} for p in dropped
+            ],
+        }
     return CallToolResult(
         content=[TextContent(type="text", text=text)],
         structured_content=structured,
@@ -620,29 +786,54 @@ async def _invoke(arguments: dict[str, Any] | None, *, reply: bool) -> CallToolR
     )
 
 
-async def codex(arguments: dict[str, Any] | None) -> CallToolResult:
-    return await _invoke(arguments, reply=False)
+async def codex(
+    arguments: dict[str, Any] | None, *, report_progress: _ReportProgress | None = None
+) -> CallToolResult:
+    return await _invoke(arguments, reply=False, report_progress=report_progress)
 
 
-async def codex_reply(arguments: dict[str, Any] | None) -> CallToolResult:
-    return await _invoke(arguments, reply=True)
+async def codex_reply(
+    arguments: dict[str, Any] | None, *, report_progress: _ReportProgress | None = None
+) -> CallToolResult:
+    return await _invoke(arguments, reply=True, report_progress=report_progress)
 
 
 async def on_list_tools(
     ctx: ServerRequestContext, params: PaginatedRequestParams | None
 ) -> ListToolsResult:
-    return ListToolsResult(tools=[_CODEX_TOOL, _REPLY_TOOL])
+    # The caller cannot see the server's command line, so the `codex` schema says which
+    # parameters it already fixes, rather than inviting values that _build_argv would drop.
+    if not _SERVER_SET:
+        return ListToolsResult(tools=[_CODEX_TOOL, _REPLY_TOOL])
+    props = dict(_CODEX_PROPS)
+    for param, setting in _SERVER_SET.items():
+        props[param] = {
+            **props[param],
+            "description": (
+                f"{props[param]['description']} This server's own command line already "
+                f"sets {setting.written}, so a value passed here is ignored."
+            ),
+        }
+    codex_tool = _CODEX_TOOL.model_copy(
+        update={"input_schema": {**_CODEX_TOOL.input_schema, "properties": props}}
+    )
+    return ListToolsResult(tools=[codex_tool, _REPLY_TOOL])
 
 
-async def on_call_tool(ctx: ServerRequestContext, params: CallToolRequestParams) -> CallToolResult:
+async def on_call_tool(
+    ctx: ServerRequestContext | None, params: CallToolRequestParams
+) -> CallToolResult:
     # An escaping exception would become a JSON-RPC error, which clients treat as a transport
     # failure rather than as something to show the model. CancelledError derives from
     # BaseException, so peer cancellation still propagates and _run_codex's killpg still runs.
+    # The session is scoped to this request, so its progress goes out against this call's
+    # token. Tests and direct callers pass no context; such a call simply sends no progress.
+    report_progress = ctx.session.report_progress if ctx is not None else None
     try:
         if params.name == "codex":
-            return await codex(params.arguments)
+            return await codex(params.arguments, report_progress=report_progress)
         if params.name == "codex-reply":
-            return await codex_reply(params.arguments)
+            return await codex_reply(params.arguments, report_progress=report_progress)
         return _error_result(f"unknown tool: {params.name}")
     except Exception as exc:
         logger.exception("%s failed", params.name)
@@ -691,7 +882,7 @@ def main() -> None:
     if sys.argv[1:] == ["--version"]:
         print(f"{_PKG_NAME} {_pkg_version(_PKG_NAME)}")
         return
-    SERVER_ARGS[:] = sys.argv[1:]
+    _set_server_args(sys.argv[1:])
     asyncio.run(_amain())
 
 

{codex_cli_mcp_slim-0.1.0 → codex_cli_mcp_slim-0.1.2/src/codex_cli_mcp_slim.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: codex-cli-mcp-slim
-Version: 0.1.0
+Version: 0.1.2
 Summary: A thin, auditable MCP server wrapping the Codex CLI (codex exec). Same tools as the deprecated `codex mcp-server`; forward-compatible with future CLI flags via extra_args passthrough.
 Author-email: tksfjt1024 <tksfjt1024@gmail.com>
 License: MIT
@@ -171,7 +171,9 @@ After:
 Parameter names differ from the old server where `codex exec` names the flag
 differently: `cwd` is now `cd` (the `-C/--cd` flag), and `codex-reply` takes
 `thread_id` instead of `threadId`. The result's `structuredContent` field keeps
-the shape the old server returned, `{"threadId": ..., "content": ...}`.
+the shape the old server returned, `{"threadId": ..., "content": ...}`. It
+gains an `ignoredParameters` key only when the server's own flags overrode a
+per-call parameter (see [Server-level flags](#server-level-flags)).
 
 ### Other MCP clients
 
@@ -207,11 +209,25 @@ in reasoning effort look like this:
 
 A call to `codex-high` runs
 `codex exec -c model_reasoning_effort=high [per-call flags] --json -`. Per-call
-flags come after the server-level ones, and `-c` may repeat with the last one
-winning, so a per-call `config` entry overrides a server-level `-c`. Single-value
-flags such as `-m` and `-C` may not repeat: `codex` rejects the second one, and
-the tool result carries that error. Keep server-level flags and per-call
-parameters disjoint for those.
+flags come after the server-level ones. `-c` and `--add-dir` may repeat. For
+`-c` the last one wins, so a per-call `config` entry overrides a server-level
+`-c`.
+
+The other typed flags (`-C`, `-m`, `--sandbox`, `-p`, `--ephemeral`,
+`--skip-git-repo-check`) may appear only once: `codex` exits with "cannot be used
+multiple times" on a second one. When the server's command line already sets one
+of them, in any spelling (for example `-C DIR`, `-CDIR`, `--cd=DIR`), the
+server-level value wins. A token that is another flag's value (the `-m` in
+`-c -m`) or that comes after `--` does not count as setting a flag. The `codex`
+tool leaves the matching per-call parameter (`cd`, `model`, `sandbox`,
+`profile`, `ephemeral`, `skip_git_repo_check`) out of the command and names it
+in the result together with the server-level value used instead: in the text
+after the `[codex]` line (`cd="/other"; this server runs with -C /srv`) and in
+`structuredContent.ignoredParameters`. Its schema tells the caller which
+parameters the server already sets, and to what. `codex-reply` keeps such
+parameters, because after `resume` they are the subcommand's own flags and
+`codex` accepts them there. `extra_args` is passed through unchecked, so a flag
+repeated through it still fails with `codex`'s own error.
 
 ## Tool: `codex`
 
@@ -226,7 +242,10 @@ The tool returns that final message followed by one metadata line:
 ```
 
 `thread_id` and `status` are always present; the token fields appear when the
-run reported them. `isError` is the flag on an MCP tool result that tells the
+run reported them. A per-call parameter that a server-level flag overrode is
+named after this line, with the value used instead (see
+[Server-level flags](#server-level-flags)).
+`isError` is the flag on an MCP tool result that tells the
 client a call failed. This server sets it when `codex` exited non-zero, when the
 subprocess timed out, and when the turn itself failed. The last case matters
 because `codex exec` exits 0 after a failure inside the model API; the tool
@@ -309,6 +328,31 @@ buffered output and reap the process, so the effective ceiling is
 `timeout_seconds + 20`. A timed-out call is flagged `isError` and carries
 whatever `codex` had printed so far.
 
+An MCP client may give up on a call that has sent neither a response nor a
+progress notification for a while. Claude Code 2.1.318 does so after 1800
+seconds by default for a stdio server ("sent no response or progress for
+1800s"), and a long `codex` turn can take longer than that. While `codex` runs,
+the server therefore sends a `notifications/progress` message every 60 seconds,
+so the call lasts until `codex` finishes or `timeout_seconds` runs out. A client
+gets these only when it sent a `progressToken` with the call, as Claude Code
+does; a client that gives up after less than 60 seconds without progress is not
+covered. With the default `timeout_seconds` of 1800 the call still ends after
+about 30 minutes, at the server's own timeout, so to let `codex` run longer,
+raise `timeout_seconds` (30 to 3600 per call) or `$CODEX_CLI_MCP_SLIM_TIMEOUT`,
+which sets the default. In the notification's `params`, `progress` counts the
+notifications sent so far and `message` says how long `codex` has been running:
+
+```json
+{
+  "jsonrpc": "2.0",
+  "method": "notifications/progress",
+  "params": {"progressToken": 7, "progress": 2, "message": "codex running for 120s"}
+}
+```
+
+If sending a notification raises an error, the server logs it to stderr and the
+call and its result are unaffected.
+
 ## Forward-compatibility example
 
 If a future `codex exec` release adds a new flag (say `--super-mode`), use it

{codex_cli_mcp_slim-0.1.0 → codex_cli_mcp_slim-0.1.2}/src/codex_cli_mcp_slim.egg-info/SOURCES.txt

@@ -12,5 +12,6 @@ src/codex_cli_mcp_slim.egg-info/requires.txt
 src/codex_cli_mcp_slim.egg-info/top_level.txt
 tests/test_basic.py
 tests/test_call_tool.py
+tests/test_progress.py
 tests/test_subprocess_stdin_isolation.py
 tests/test_timeout_handling.py