python-agent-harness 1.5.5.9__tar.gz → 1.5.6.1__tar.gz

{python_agent_harness-1.5.5.9/python_agent_harness.egg-info → python_agent_harness-1.5.6.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: python-agent-harness
-Version: 1.5.5.9
+Version: 1.5.6.1
 Summary: A lightweight, hackable mini-OpenCode written in Python.
 Author-email: Huming Chen <chenhuming@gmail.com>
 License-Expression: MIT
@@ -9,7 +9,6 @@ Classifier: Development Status :: 5 - Production/Stable
 Classifier: Environment :: Console
 Classifier: Intended Audience :: Developers
 Classifier: Operating System :: MacOS
-Classifier: Operating System :: Microsoft :: Windows
 Classifier: Operating System :: POSIX :: Linux
 Classifier: Programming Language :: Python :: 3.11
 Classifier: Programming Language :: Python :: 3.12
@@ -20,6 +19,7 @@ Description-Content-Type: text/markdown
 License-File: LICENSE
 Requires-Dist: rich>=13.0
 Requires-Dist: httpx>=0.27
+Requires-Dist: certifi>=2024.0
 Requires-Dist: prompt_toolkit>=3.0
 Provides-Extra: mcp
 Requires-Dist: mcp<3,>=2.0; extra == "mcp"
@@ -113,6 +113,7 @@ Edit `~/.config/python-agent-harness/config.json` and set your `base_url`, `api_
 - **MCP support** — optional MCP integration through the `[mcp]` extra. MCP tools become ordinary agent tools such as `mcp__<server>__<tool>`. Supports `stdio`, `streamable-http`, and `sse` transports.
 - **Slash commands** — built-in `/init`, `/review`, `/explain`, and other commands, plus custom commands loaded from `prompts/commands/*.md`.
 - **Custom agents** — switch the main agent's system prompt at runtime with `/agent`. Agent prompt files live in `prompts/agents/*.md`. Use `default_agent` in the config file to start sessions with a specific agent.
+- **Embeddable runtime boundaries** — drive the agent from programs: `headless --json` for one-shot CI/scripting (write-only JSONL stream), `serve` for hosting apps (resident process, bidirectional protocol: multi-turn memory, mid-run Q&A, protocol-level cancel).
 
 ## Inspired by opencode
 
@@ -221,6 +222,8 @@ All LLM settings live in a single JSON configuration file. Environment variables
 - **`paths.context_path` / `paths.skill_path`** — locations from which to load context files and skills. When unset, the project-local `<project>/contexts` and `<project>/skills` directories are used.
 - **`lsp.servers`** — optional per-extension LSP server overrides for the `LSP` code-intelligence tool. Keys are file extensions (e.g. `.py`, `.cpp`); each value has a `command` (the server argv) and an optional `language_id` (defaults to the extension without its dot). These layer on top of the built-in `DEFAULT_SERVERS` table in `lsp/manager.py`; an entry for an existing extension replaces its default. The server binary must be on `PATH`.
 - **`mcp.servers`** — MCP server configuration. Requires the `[mcp]` extra. Each server supports `transport`, `command`, `args`, `env`, `url`, `headers`, `parallel`, `timeout`, and `enabled`.
+- **`headless`** — optional server-side limits for unattended `headless` runs: `max_rounds` caps LLM rounds and `timeout` caps wall-clock seconds. `--max-rounds` / `--timeout` override these per call; values `<= 0` or `null` disable. Unset = unlimited (interactive behavior).
+- **`serve`** — the same two keys for the resident `serve` server, applied to **each** run rather than the process: the server is resident, so every `submit` gets a fresh budget. Enforced in-process so a driving host cannot raise its own ceiling — the ceiling belongs to whoever starts the sandbox. A tripped budget ends the run with a normal `result` line carrying `errors[].code` of `budget` or `timeout` plus the token usage consumed. `--max-rounds` / `--timeout` override these; values `<= 0` or `null` disable. Unset = unlimited.
 - **Configuration precedence** — code defaults < config file < `OPENAI_*` environment variables. Sub-agent settings also support `OPENAI_SUBAGENT_*` (`_BASE_URL`, `_API_KEY`, `_MODEL`).
 - **Custom config** — use `--config PATH` or `PYTHON_AGENT_HARNESS_CONFIG`.
 - **LLM logging** — request and response bodies are logged as JSON to `/tmp/python-agent-harness-<date>-<id>.json`. Set `LLM_LOG_DIR` to change the directory. The log path is printed at startup.
@@ -270,9 +273,16 @@ Interactive prompts are auto-answered (`confirm` → yes, `ask` →
   one `{"type": ...}` object per line: `start` (echoes the prompt and
   submit warnings), `delta` (streamed text chunks), `notify` (tool and
   status events, with `kind`/`data`), `log`, and a final `result` (the
-  filtered answer plus any `errors`). Diagnostics (restore/model notes,
-  a plain-text echo of error events) still go to stderr, so one pipe
-  carries the structured stream. Exit codes are unchanged.
+  filtered answer plus any `errors`).  Every line carries `protocol`
+  (the wire schema version — reject an unknown version before
+  consuming events) and `seq` (a per-stream monotonic counter for
+  drop/reorder detection).  The `result` line reports `errors` as a
+  structured list of `{"code", "message"}` objects (codes: `budget`,
+  `timeout`, `nothing`, `restore`, `no_answer`, `unknown`, ...) with an
+  `error_messages` flat-string mirror for simple drivers.  Diagnostics
+  (restore/model notes, a plain-text echo of error events) still go to
+  stderr, so one pipe carries the structured stream.  Exit codes are
+  unchanged.
 
   ```sh
   python-agent-harness headless "fix it" --json | jq -c 'select(.type=="result")'
@@ -281,6 +291,113 @@ Interactive prompts are auto-answered (`confirm` → yes, `ask` →
 - Exit code is 0 on success, 1 when the prompt was empty (only failed
   `@file` references), the run raised an agent error, or the restore failed.
 
+### Serve mode (resident JSONL server)
+
+```sh
+python-agent-harness serve [--project DIR] [--answer-timeout SECONDS]
+                           [--max-rounds N] [--timeout SECONDS]
+```
+
+A persistent, bidirectional runtime boundary for hosting applications
+(a web backend, an IDE, a CI driver).  Unlike `headless --json` (one
+prompt per process, write-only stream), `serve` keeps the
+`Controller`/`Session` resident and speaks a request/response protocol
+over stdin/stdout — the same process boundary (containerizable), but
+the host can:
+
+- submit multiple prompts over the process's lifetime — no per-turn
+  interpreter spawn, and conversation history is retained between them
+  (multi-turn memory);
+- answer the agent's mid-run questions (the `Question` tool and
+  plan-exit confirmation) via an `answer` op;
+- cancel a run as a protocol message (no signal semantics).
+
+Protocol (one JSON object per line):
+
+```
+host → agent: {"op": "submit", "prompt": ..., "run_id": ...}
+              {"op": "answer", "run_id": ..., "answers": [...], "ask_id": ...}
+              {"op": "cancel", "run_id": ...}
+              {"op": "hello", "protocol_versions": [...]}
+              {"op": "ping"} | {"op": "shutdown"}
+              ... any op may carry "op_id", echoed on what it causes
+agent → host: {"protocol": V, "type": "ready", "pid": ...,
+               "protocol_version": V, "capabilities": [...]}   first line
+              {"protocol": V, "type": "hello", "protocol_version": V,
+               "capabilities": [...], "op_id": ...}   negotiation reply
+              {"protocol": V, "seq": N, "type": "start"|"delta"|"notify"|"log",
+               "run_id": ...}
+              {"protocol": V, "seq": N, "type": "result", "run_id": ...,
+               "answer": ..., "errors": [{"code", "message"}],
+               "error_messages": [...], "usage": {...}, "cancelled": bool}
+              {"protocol": V, "type": "error",
+               "error": {"code": "protocol", "message": ...},
+               "message": ...}                      protocol failures
+```
+
+Version negotiation runs both ways.  `ready` announces what the build
+speaks — a single integer a host can only accept or reject wholesale.
+`hello` is the other direction: the host states the versions *it* can
+parse and the server confirms a shared one or refuses with a
+`protocol` error, so a mismatch is settled once, before any run,
+rather than surfacing as misparsed events.  With one line shape today
+the only outcomes are "agreed" or "no overlap", but it is the hook a
+future version needs in order to downgrade instead of breaking an
+older host.  Both halves are advertised as the `hello` capability.
+
+There is no generic `ack`: each op is acknowledged by its own effect
+on the stream.  Failures are the exception, because an effect that
+never happened cannot be correlated — so an op may carry an `op_id`,
+echoed on the `error` (or `pong`) it causes.  A host that pipelined an
+`answer` and a `cancel` can then tell which one was refused instead of
+seeing two indistinguishable error lines.  Advertised as the `op_id`
+capability; omitting the field keeps the older behaviour.
+
+A mid-run question arrives as a `notify` with `kind: "ask"` (data has
+`kind: "ask"|"confirm"` and an `ask_id`); reply with `answer`, echoing
+the `ask_id` so the reply is matched to its question.  A mismatched id
+is refused rather than applied to whatever is pending — otherwise a
+reply sent for a question that has since timed out would resolve the
+*next* one.  Omitting `ask_id` keeps the older behaviour, except once
+some ask in the run has timed out, when an uncorrelated answer is
+ambiguous and is refused.
+
+One run at a time; a `submit` while one is active is rejected with an
+`error` line.  `--answer-timeout SECONDS` bounds how long a pending
+question waits for the host's answer (default: forever).  The result
+line's shape is identical to `headless --json`'s, so a driver can
+speak both protocols with one parser.
+
+`ready` carries a `capabilities` list naming the features the build
+supports, so a host can adapt instead of inferring a feature's absence
+from events that never arrive.  A `notify` of kind `usage` reports the
+run's running `{input, output, rounds}` after each round, so a host can
+meter mid-run and `cancel` a run that outruns its budget rather than
+learning the cost only from the terminal `result`.  Classified
+failures carry their code from the raise site (`errors[].code` of
+`budget` or `timeout`), so a driver never has to match words in a
+human-readable message.
+
+`--max-rounds N` and `--timeout SECONDS` (or the config file's `serve`
+section) bound **each** run rather than the process — the resident
+server grants every `submit` a fresh budget.  Both are off by default.
+They are deliberately not fields on the `submit` op: `serve` sandboxes
+untrusted agent code on a host's behalf, so the ceiling belongs to
+whoever starts the sandbox, not to the caller.  A tripped budget
+unwinds the agent loop through its normal path, so the run still ends
+with a `result` line carrying `errors[].code` of `budget` or `timeout`
+plus the token usage consumed — a host bills and reports it like any
+other outcome.
+
+`timeout` is **cooperative** — checked between rounds, not by a
+watchdog — so it bounds work at those checkpoints but does not
+forcibly interrupt a blocking operation mid-round (a hung tool, a slow
+network read, or a run parked on a mid-run question awaiting a human
+answer). Use `--answer-timeout` to cap how long an ask waits, and rely
+on the hosting process's own exec watchdog (which sends `cancel` then
+kills) as the hard wall-clock stop for anything the cooperative budget
+cannot reach.
+
 ### Slash commands
 
 | Command | Description |
@@ -297,6 +414,7 @@ Interactive prompts are auto-answered (`confirm` → yes, `ask` →
 | `/clear` | Start a fresh conversation |
 | `/model [name]` | Switch LLM profiles; `default` restores the session's original model |
 | `/agent [name]` | Switch agent system prompt; `default` restores the built-in `agent.md` |
+| `/help` | List the available commands |
 | `/exit` | Quit |
 
 Custom commands from `prompts/commands/*.md` are registered as slash commands as well (TUI only).
@@ -335,18 +453,19 @@ You are a personal assistant. You do NOT modify files or run shell commands.
 
 ## Development
 
-Requires Python ≥ 3.11. CI runs against Python 3.11, 3.12, and 3.13 on Linux, MacOS and Windows.
+Requires Python ≥ 3.11. CI runs against Python 3.11, 3.12, and 3.13 on Linux and MacOS.
 
 ```sh
 make test                           # unit tests
 venv/bin/pip install -e ".[dev]"    # development tools
 venv/bin/ruff check .               # lint
+venv/bin/ruff format --check .      # formatting (CI blocks on this too)
 venv/bin/pyright                    # type checking
 venv/bin/python -m build            # build sdist + wheel
 venv/bin/pip-audit                  # dependency audit
 ```
 
-CI blocks on Ruff and Pyright failures.
+CI blocks on Ruff (lint **and** `format --check`) and Pyright failures.
 
 ## Design philosophy
 

{python_agent_harness-1.5.5.9 → python_agent_harness-1.5.6.1}/README.md

@@ -79,6 +79,7 @@ Edit `~/.config/python-agent-harness/config.json` and set your `base_url`, `api_
 - **MCP support** — optional MCP integration through the `[mcp]` extra. MCP tools become ordinary agent tools such as `mcp__<server>__<tool>`. Supports `stdio`, `streamable-http`, and `sse` transports.
 - **Slash commands** — built-in `/init`, `/review`, `/explain`, and other commands, plus custom commands loaded from `prompts/commands/*.md`.
 - **Custom agents** — switch the main agent's system prompt at runtime with `/agent`. Agent prompt files live in `prompts/agents/*.md`. Use `default_agent` in the config file to start sessions with a specific agent.
+- **Embeddable runtime boundaries** — drive the agent from programs: `headless --json` for one-shot CI/scripting (write-only JSONL stream), `serve` for hosting apps (resident process, bidirectional protocol: multi-turn memory, mid-run Q&A, protocol-level cancel).
 
 ## Inspired by opencode
 
@@ -187,6 +188,8 @@ All LLM settings live in a single JSON configuration file. Environment variables
 - **`paths.context_path` / `paths.skill_path`** — locations from which to load context files and skills. When unset, the project-local `<project>/contexts` and `<project>/skills` directories are used.
 - **`lsp.servers`** — optional per-extension LSP server overrides for the `LSP` code-intelligence tool. Keys are file extensions (e.g. `.py`, `.cpp`); each value has a `command` (the server argv) and an optional `language_id` (defaults to the extension without its dot). These layer on top of the built-in `DEFAULT_SERVERS` table in `lsp/manager.py`; an entry for an existing extension replaces its default. The server binary must be on `PATH`.
 - **`mcp.servers`** — MCP server configuration. Requires the `[mcp]` extra. Each server supports `transport`, `command`, `args`, `env`, `url`, `headers`, `parallel`, `timeout`, and `enabled`.
+- **`headless`** — optional server-side limits for unattended `headless` runs: `max_rounds` caps LLM rounds and `timeout` caps wall-clock seconds. `--max-rounds` / `--timeout` override these per call; values `<= 0` or `null` disable. Unset = unlimited (interactive behavior).
+- **`serve`** — the same two keys for the resident `serve` server, applied to **each** run rather than the process: the server is resident, so every `submit` gets a fresh budget. Enforced in-process so a driving host cannot raise its own ceiling — the ceiling belongs to whoever starts the sandbox. A tripped budget ends the run with a normal `result` line carrying `errors[].code` of `budget` or `timeout` plus the token usage consumed. `--max-rounds` / `--timeout` override these; values `<= 0` or `null` disable. Unset = unlimited.
 - **Configuration precedence** — code defaults < config file < `OPENAI_*` environment variables. Sub-agent settings also support `OPENAI_SUBAGENT_*` (`_BASE_URL`, `_API_KEY`, `_MODEL`).
 - **Custom config** — use `--config PATH` or `PYTHON_AGENT_HARNESS_CONFIG`.
 - **LLM logging** — request and response bodies are logged as JSON to `/tmp/python-agent-harness-<date>-<id>.json`. Set `LLM_LOG_DIR` to change the directory. The log path is printed at startup.
@@ -236,9 +239,16 @@ Interactive prompts are auto-answered (`confirm` → yes, `ask` →
   one `{"type": ...}` object per line: `start` (echoes the prompt and
   submit warnings), `delta` (streamed text chunks), `notify` (tool and
   status events, with `kind`/`data`), `log`, and a final `result` (the
-  filtered answer plus any `errors`). Diagnostics (restore/model notes,
-  a plain-text echo of error events) still go to stderr, so one pipe
-  carries the structured stream. Exit codes are unchanged.
+  filtered answer plus any `errors`).  Every line carries `protocol`
+  (the wire schema version — reject an unknown version before
+  consuming events) and `seq` (a per-stream monotonic counter for
+  drop/reorder detection).  The `result` line reports `errors` as a
+  structured list of `{"code", "message"}` objects (codes: `budget`,
+  `timeout`, `nothing`, `restore`, `no_answer`, `unknown`, ...) with an
+  `error_messages` flat-string mirror for simple drivers.  Diagnostics
+  (restore/model notes, a plain-text echo of error events) still go to
+  stderr, so one pipe carries the structured stream.  Exit codes are
+  unchanged.
 
   ```sh
   python-agent-harness headless "fix it" --json | jq -c 'select(.type=="result")'
@@ -247,6 +257,113 @@ Interactive prompts are auto-answered (`confirm` → yes, `ask` →
 - Exit code is 0 on success, 1 when the prompt was empty (only failed
   `@file` references), the run raised an agent error, or the restore failed.
 
+### Serve mode (resident JSONL server)
+
+```sh
+python-agent-harness serve [--project DIR] [--answer-timeout SECONDS]
+                           [--max-rounds N] [--timeout SECONDS]
+```
+
+A persistent, bidirectional runtime boundary for hosting applications
+(a web backend, an IDE, a CI driver).  Unlike `headless --json` (one
+prompt per process, write-only stream), `serve` keeps the
+`Controller`/`Session` resident and speaks a request/response protocol
+over stdin/stdout — the same process boundary (containerizable), but
+the host can:
+
+- submit multiple prompts over the process's lifetime — no per-turn
+  interpreter spawn, and conversation history is retained between them
+  (multi-turn memory);
+- answer the agent's mid-run questions (the `Question` tool and
+  plan-exit confirmation) via an `answer` op;
+- cancel a run as a protocol message (no signal semantics).
+
+Protocol (one JSON object per line):
+
+```
+host → agent: {"op": "submit", "prompt": ..., "run_id": ...}
+              {"op": "answer", "run_id": ..., "answers": [...], "ask_id": ...}
+              {"op": "cancel", "run_id": ...}
+              {"op": "hello", "protocol_versions": [...]}
+              {"op": "ping"} | {"op": "shutdown"}
+              ... any op may carry "op_id", echoed on what it causes
+agent → host: {"protocol": V, "type": "ready", "pid": ...,
+               "protocol_version": V, "capabilities": [...]}   first line
+              {"protocol": V, "type": "hello", "protocol_version": V,
+               "capabilities": [...], "op_id": ...}   negotiation reply
+              {"protocol": V, "seq": N, "type": "start"|"delta"|"notify"|"log",
+               "run_id": ...}
+              {"protocol": V, "seq": N, "type": "result", "run_id": ...,
+               "answer": ..., "errors": [{"code", "message"}],
+               "error_messages": [...], "usage": {...}, "cancelled": bool}
+              {"protocol": V, "type": "error",
+               "error": {"code": "protocol", "message": ...},
+               "message": ...}                      protocol failures
+```
+
+Version negotiation runs both ways.  `ready` announces what the build
+speaks — a single integer a host can only accept or reject wholesale.
+`hello` is the other direction: the host states the versions *it* can
+parse and the server confirms a shared one or refuses with a
+`protocol` error, so a mismatch is settled once, before any run,
+rather than surfacing as misparsed events.  With one line shape today
+the only outcomes are "agreed" or "no overlap", but it is the hook a
+future version needs in order to downgrade instead of breaking an
+older host.  Both halves are advertised as the `hello` capability.
+
+There is no generic `ack`: each op is acknowledged by its own effect
+on the stream.  Failures are the exception, because an effect that
+never happened cannot be correlated — so an op may carry an `op_id`,
+echoed on the `error` (or `pong`) it causes.  A host that pipelined an
+`answer` and a `cancel` can then tell which one was refused instead of
+seeing two indistinguishable error lines.  Advertised as the `op_id`
+capability; omitting the field keeps the older behaviour.
+
+A mid-run question arrives as a `notify` with `kind: "ask"` (data has
+`kind: "ask"|"confirm"` and an `ask_id`); reply with `answer`, echoing
+the `ask_id` so the reply is matched to its question.  A mismatched id
+is refused rather than applied to whatever is pending — otherwise a
+reply sent for a question that has since timed out would resolve the
+*next* one.  Omitting `ask_id` keeps the older behaviour, except once
+some ask in the run has timed out, when an uncorrelated answer is
+ambiguous and is refused.
+
+One run at a time; a `submit` while one is active is rejected with an
+`error` line.  `--answer-timeout SECONDS` bounds how long a pending
+question waits for the host's answer (default: forever).  The result
+line's shape is identical to `headless --json`'s, so a driver can
+speak both protocols with one parser.
+
+`ready` carries a `capabilities` list naming the features the build
+supports, so a host can adapt instead of inferring a feature's absence
+from events that never arrive.  A `notify` of kind `usage` reports the
+run's running `{input, output, rounds}` after each round, so a host can
+meter mid-run and `cancel` a run that outruns its budget rather than
+learning the cost only from the terminal `result`.  Classified
+failures carry their code from the raise site (`errors[].code` of
+`budget` or `timeout`), so a driver never has to match words in a
+human-readable message.
+
+`--max-rounds N` and `--timeout SECONDS` (or the config file's `serve`
+section) bound **each** run rather than the process — the resident
+server grants every `submit` a fresh budget.  Both are off by default.
+They are deliberately not fields on the `submit` op: `serve` sandboxes
+untrusted agent code on a host's behalf, so the ceiling belongs to
+whoever starts the sandbox, not to the caller.  A tripped budget
+unwinds the agent loop through its normal path, so the run still ends
+with a `result` line carrying `errors[].code` of `budget` or `timeout`
+plus the token usage consumed — a host bills and reports it like any
+other outcome.
+
+`timeout` is **cooperative** — checked between rounds, not by a
+watchdog — so it bounds work at those checkpoints but does not
+forcibly interrupt a blocking operation mid-round (a hung tool, a slow
+network read, or a run parked on a mid-run question awaiting a human
+answer). Use `--answer-timeout` to cap how long an ask waits, and rely
+on the hosting process's own exec watchdog (which sends `cancel` then
+kills) as the hard wall-clock stop for anything the cooperative budget
+cannot reach.
+
 ### Slash commands
 
 | Command | Description |
@@ -263,6 +380,7 @@ Interactive prompts are auto-answered (`confirm` → yes, `ask` →
 | `/clear` | Start a fresh conversation |
 | `/model [name]` | Switch LLM profiles; `default` restores the session's original model |
 | `/agent [name]` | Switch agent system prompt; `default` restores the built-in `agent.md` |
+| `/help` | List the available commands |
 | `/exit` | Quit |
 
 Custom commands from `prompts/commands/*.md` are registered as slash commands as well (TUI only).
@@ -301,18 +419,19 @@ You are a personal assistant. You do NOT modify files or run shell commands.
 
 ## Development
 
-Requires Python ≥ 3.11. CI runs against Python 3.11, 3.12, and 3.13 on Linux, MacOS and Windows.
+Requires Python ≥ 3.11. CI runs against Python 3.11, 3.12, and 3.13 on Linux and MacOS.
 
 ```sh
 make test                           # unit tests
 venv/bin/pip install -e ".[dev]"    # development tools
 venv/bin/ruff check .               # lint
+venv/bin/ruff format --check .      # formatting (CI blocks on this too)
 venv/bin/pyright                    # type checking
 venv/bin/python -m build            # build sdist + wheel
 venv/bin/pip-audit                  # dependency audit
 ```
 
-CI blocks on Ruff and Pyright failures.
+CI blocks on Ruff (lint **and** `format --check`) and Pyright failures.
 
 ## Design philosophy
 

{python_agent_harness-1.5.5.9 → python_agent_harness-1.5.6.1}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "python-agent-harness"
-version = "1.5.5.9"
+version = "1.5.6.1"
 description = "A lightweight, hackable mini-OpenCode written in Python."
 authors = [
     {name = "Huming Chen", email = "chenhuming@gmail.com"}
@@ -17,7 +17,6 @@ classifiers = [
     "Environment :: Console",
     "Intended Audience :: Developers",
     "Operating System :: MacOS",
-    "Operating System :: Microsoft :: Windows",
     "Operating System :: POSIX :: Linux",
     "Programming Language :: Python :: 3.11",
     "Programming Language :: Python :: 3.12",
@@ -27,6 +26,7 @@ classifiers = [
 dependencies = [
     "rich>=13.0",
     "httpx>=0.27",
+    "certifi>=2024.0",
     "prompt_toolkit>=3.0",
 ]
 
@@ -96,8 +96,4 @@ omit = [
 
 [tool.coverage.report]
 show_missing = true
-# Linux/macOS gate: 95%.  Windows CI enforces 94% with tools/bash.py
-# omitted instead (see .github/workflows/ci.yml): that module is the
-# posix PTY/spawn backend whose body cannot execute on Windows, where
-# tools/bash_win.py runs in its place.
 fail_under = 95

{python_agent_harness-1.5.5.9 → python_agent_harness-1.5.6.1}/python_agent_harness/__init__.py

@@ -8,7 +8,7 @@ from .mcp.config import MCPConfig, MCPServerConfig
 from .mcp.manager import MCPManager
 from .session.session import Session
 
-__version__ = "1.5.5.9"
+__version__ = "1.5.6.1"
 
 __all__ = [
     "Client",