Integrate Harness APIs - #680
Conversation
… interface (#682) * Create hosted-agent sessions from an agents.yaml manifest The harness-api backend provisions a session entirely from the agent spec, so replace the legacy JSON create(agent_kind=...) with create_from_manifest(), which uploads the manifest verbatim as Content-Type: application/x-yaml. The spec defines the runtime adapter, sandbox, env vars, and egress; there are no other arguments. - Add create_from_manifest() to the sync and async session clients, sharing manifest-normalization and YAML media-type helpers. - Remove the now-unsupported create(agent_kind=...) path. - Point the create_session.py example at a spec file and add session_e2e.py demonstrating the full create -> attach (send a prompt, stream SSE back) -> destroy flow. - Cover manifest upload in the sync and new async unit tests; drop the legacy create test. * regenerate fix * fix --------- Co-authored-by: SSharma-10 <shivanisharma@digitalocean.com>
Four standalone scripts exercising the permissions block:
- policy_auto_allow.py — touch * → allow runs without HITL
- policy_auto_deny.py — ls * → deny blocks without HITL prompt
- policy_hitl_ask.py — defaultAction: ask gates unmatched commands;
tests both approve and reject resolution paths
- policy_write_interception.py — Write/Edit (non-Bash) tool intercepted
under defaultAction: ask
All scripts load the base AGENT_SPEC, inject a permissions block, and
assert pass/fail without external YAML files.
![semgrep-code-digitalocean[bot]](https://avatars.githubusercontent.com/in/1159782?s=60&v=4){kind=small}
| for chunk in chunks: | ||
| yield chunk | ||
| return | ||
| async with aiohttp.ClientSession() as session: |
There was a problem hiding this comment.
Medium severity and reachable issue identified in your code:
Line 82 has a vulnerable usage of aiohttp, introducing a medium severity vulnerability.
ℹ️ Why this is reachable
A reachable issue is a real security risk because your project actually executes the vulnerable code. This issue is reachable because your code uses a certain version of aiohttp.
Affected versions of aiohttp are vulnerable to Allocation of Resources Without Limits or Throttling / Uncontrolled Resource Consumption. aiohttp does not limit the number of HTTP header/trailer lines it parses. An attacker who controls a request (against an aiohttp server) or a response (against an aiohttp client) can send an unbounded number of trailer/header lines, causing uncapped memory consumption and denial of service. The vulnerable HTTP parser (HttpRequestParser/HttpResponseParser) is exercised by any aiohttp server accepting requests or any aiohttp client receiving responses, so there is no distinguishing code path to key on. Upgrade to aiohttp 3.13.4 or later.
To resolve this comment:
Upgrade this dependency to at least version 3.13.4 at requirements.txt.
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Questions about this issue? Reach out to Product Security in #prodsec-tools.
You can view more details on this finding in the Semgrep AppSec Platform here.
| # Fallback for environments without the aio extra. | ||
| await _run_sync(_http_put_bytes, url, data) | ||
| return | ||
| async with aiohttp.ClientSession() as session: |
There was a problem hiding this comment.
Medium severity and reachable issue identified in your code:
Line 61 has a vulnerable usage of aiohttp, introducing a medium severity vulnerability.
ℹ️ Why this is reachable
A reachable issue is a real security risk because your project actually executes the vulnerable code. This issue is reachable because your code uses a certain version of aiohttp.
Affected versions of aiohttp are vulnerable to Allocation of Resources Without Limits or Throttling / Uncontrolled Resource Consumption. aiohttp does not limit the number of HTTP header/trailer lines it parses. An attacker who controls a request (against an aiohttp server) or a response (against an aiohttp client) can send an unbounded number of trailer/header lines, causing uncapped memory consumption and denial of service. The vulnerable HTTP parser (HttpRequestParser/HttpResponseParser) is exercised by any aiohttp server accepting requests or any aiohttp client receiving responses, so there is no distinguishing code path to key on. Upgrade to aiohttp 3.13.4 or later.
To resolve this comment:
Upgrade this dependency to at least version 3.13.4 at requirements.txt.
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Questions about this issue? Reach out to Product Security in #prodsec-tools.
You can view more details on this finding in the Semgrep AppSec Platform here.
| for chunk in chunks: | ||
| yield chunk | ||
| return | ||
| async with aiohttp.ClientSession() as session: |
There was a problem hiding this comment.
Medium severity and reachable issue identified in your code:
Line 82 has a vulnerable usage of aiohttp, introducing a medium severity vulnerability.
ℹ️ Why this is reachable
A reachable issue is a real security risk because your project actually executes the vulnerable code. This issue is reachable because your code uses a certain version of aiohttp.
Affected versions of aiohttp are vulnerable to Allocation of Resources Without Limits or Throttling. The optimized C HTTP parser in aiohttp validates each fragment of an HTTP request/response line individually against max_line_size instead of the accumulated total. An attacker can split an oversized line across multiple network reads, bypassing the limit and causing excessive memory consumption, leading to denial of service. This affects both server-side request-target parsing and client-side response reason-phrase parsing.
References: GHSA
To resolve this comment:
Upgrade this dependency to at least version 3.14.1 at requirements.txt.
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Questions about this issue? Reach out to Product Security in #prodsec-tools.
You can view more details on this finding in the Semgrep AppSec Platform here.
| # Fallback for environments without the aio extra. | ||
| await _run_sync(_http_put_bytes, url, data) | ||
| return | ||
| async with aiohttp.ClientSession() as session: |
There was a problem hiding this comment.
Medium severity and reachable issue identified in your code:
Line 61 has a vulnerable usage of aiohttp, introducing a medium severity vulnerability.
ℹ️ Why this is reachable
A reachable issue is a real security risk because your project actually executes the vulnerable code. This issue is reachable because your code uses a certain version of aiohttp.
Affected versions of aiohttp are vulnerable to Allocation of Resources Without Limits or Throttling. The optimized C HTTP parser in aiohttp validates each fragment of an HTTP request/response line individually against max_line_size instead of the accumulated total. An attacker can split an oversized line across multiple network reads, bypassing the limit and causing excessive memory consumption, leading to denial of service. This affects both server-side request-target parsing and client-side response reason-phrase parsing.
References: GHSA
To resolve this comment:
Upgrade this dependency to at least version 3.14.1 at requirements.txt.
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Questions about this issue? Reach out to Product Security in #prodsec-tools.
You can view more details on this finding in the Semgrep AppSec Platform here.
Bring Action Gateway Private Preview (PR #694) onto OHS_endpoints, keeping both hosted agents and gateway client wiring. Co-authored-by: Cursor <cursoragent@cursor.com>
…#706) harness-api now caps a cursorless /stream attach to its replay budget instead of replaying a session's entire event history, and exposes older history through the same endpoint via before/limit (cthulhu #169570). Without this, clients can only ever see the newest slice of a long-lived session, with no way to reach the rest. Adds before/limit to sessions.stream() on both the sync and async clients, forcing replay_only when before is set because the server rejects the combination otherwise, and a history_page() helper that drains one page and returns the events, has_more, and the cursor for the next page back. has_more arrives as a trailing SSE comment, which SSEStream/AsyncSSEStream previously dropped along with every other comment frame, so they now record it while continuing to ignore banners like ": connected to <session_id>". Co-authored-by: Cursor <cursoragent@cursor.com>
| yield chunk | ||
| return | ||
| async with aiohttp.ClientSession() as session: | ||
| async with session.get(url) as resp: |
There was a problem hiding this comment.
High severity and reachable issue identified in your code:
Line 84 has a vulnerable usage of aiohttp, introducing a high severity vulnerability.
ℹ️ Why this is reachable
A reachable issue is a real security risk because your project actually executes the vulnerable code. This issue is reachable because your code uses a certain version of aiohttp.
Affected versions of aiohttp are vulnerable to Out-of-bounds Read / Uncontrolled Resource Consumption / Use After Free. The compiled C HTTP parser in aiohttp builds its parse-error message from the raw llhttp error-position pointer rather than from the bounded input buffer, so Cython runs strlen() past the end of the already-released buffer. Parsing a malformed HTTP message, such as a malformed chunked response, causes an out-of-bounds heap read that can crash or hang the process. An attacker-controlled or merely malfunctioning peer can therefore cause a denial of service. Because the flawed error path lives in the shared HttpParser.feed_data base method, it is reachable both from the client via HttpResponseParser and from the server via HttpRequestParser.
References: GHSA
To resolve this comment:
Upgrade this dependency to at least version 3.14.3 at requirements.txt.
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Questions about this issue? Reach out to Product Security in #prodsec-tools.
You can view more details on this finding in the Semgrep AppSec Platform here.
| async with session.put( | ||
| url, data=data, headers={"Content-Type": _OCTET_STREAM} | ||
| ) as resp: |
There was a problem hiding this comment.
High severity and reachable issue identified in your code:
Line 63 has a vulnerable usage of aiohttp, introducing a high severity vulnerability.
ℹ️ Why this is reachable
A reachable issue is a real security risk because your project actually executes the vulnerable code. This issue is reachable because your code uses a certain version of aiohttp.
Affected versions of aiohttp are vulnerable to Out-of-bounds Read / Uncontrolled Resource Consumption / Use After Free. The compiled C HTTP parser in aiohttp builds its parse-error message from the raw llhttp error-position pointer rather than from the bounded input buffer, so Cython runs strlen() past the end of the already-released buffer. Parsing a malformed HTTP message, such as a malformed chunked response, causes an out-of-bounds heap read that can crash or hang the process. An attacker-controlled or merely malfunctioning peer can therefore cause a denial of service. Because the flawed error path lives in the shared HttpParser.feed_data base method, it is reachable both from the client via HttpResponseParser and from the server via HttpRequestParser.
References: GHSA
To resolve this comment:
Upgrade this dependency to at least version 3.14.3 at requirements.txt.
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Questions about this issue? Reach out to Product Security in #prodsec-tools.
You can view more details on this finding in the Semgrep AppSec Platform here.
5 participants
No description provided.