Raise eligible Linux child processes own oom_score_adj from a child-side /bin/sh exec shim so cgroup memory pressure prefers transient workers over the long-lived gateway. Cover supervisor children, PTY shells, MCP stdio servers, and OpenClaw-launched browser processes through the shared process runtime seam.
Harden the wrapper for distroless images, shell startup env, per-child and process-level opt-outs, dash-compatible exec, and leading-dash command names. Document Linux verification and OOM behavior.
Fixes#70404.
Co-authored-by: Neerav Makwana <261249544+neeravmakwana@users.noreply.github.com>
- Drop redundant !lastToolError check from the messaging-tool clean-stop
early return; the earlier lastToolError early return already handles
that case, so the extra condition was dead and misleading.
- Update the CHANGELOG entry to reference only stopReason=stop; the pi-ai
StopReason type does not include end_turn, so the earlier mention was
a documentation-only discrepancy.
The agent runner was surfacing a '⚠️ Agent couldn't generate a response'
warning even when the assistant had already sent user-visible content
through a messaging tool and the turn ended cleanly. Treat that path as
a successful delivery and skip the warning while keeping real failure
modes (tool errors, stopReason=error, interrupted tool use) intact.
Fixes#70396.
The tts tool previously returned a fixed "Generated audio reply."
string in its content, so session transcripts lost what was actually
spoken. Across every channel, a voice-only reply left no text record
for future turns, forcing users to recover transcripts from the
provider's API. Echo the synthesized text back in the tool result
content (audio still delivered via details.media).
Sanitize the transcript before embedding so crafted utterances cannot
inject reply directives when tool output is rendered in verbose mode:
MEDIA: at line start and [[…]] markers are interrupted with a
zero-width word joiner (U+2060) that defuses parseReplyDirectives
without altering the visible text.
* fix(amazon-bedrock-mantle): refresh IAM bearer token via resolveConfigApiKey cache lookup
The Mantle plugin generates a bearer token from IAM credentials at discovery
time and bakes it as a static string into the provider config. After the
token's cache TTL expires (~1hr), requests fail because resolveConfigApiKey
only handled the explicit AWS_BEARER_TOKEN_BEDROCK env var case.
Fix: expose getCachedIamToken() as a sync read from the existing iamTokenCache,
and wire it into resolveConfigApiKey as a fallback when no explicit env var is
set. The catalog.run still generates/refreshes the token on discovery; this
change ensures the cached token is served at auth resolution time.
Fixes#68900
* fix(amazon-bedrock-mantle): refresh runtime IAM bearer auth
* docs(changelog): note Mantle IAM refresh
* fix(agents): apply runtime auth in simple completion
---------
Co-authored-by: Vincent Koc <vincentkoc@ieee.org>
* fix: propagate AWS SDK auth sentinel for IMDS/instance role Bedrock auth
When Bedrock auth resolves via AWS SDK default credential chain (IMDS,
ECS task role) with no explicit API key, the auth controller returned
early without calling setRuntimeApiKey(). This left pi's authStorage
unaware that the provider is authenticated, causing 'No API key found
for amazon-bedrock' errors.
Now, when mode is 'aws-sdk' and no explicit API key is available:
1. Try prepareProviderRuntimeAuth to resolve runtime credentials
2. If that returns a real apiKey, use it with auth refresh scheduling
3. Otherwise inject a '__aws_sdk_auth__' sentinel so pi's
hasConfiguredAuth() passes and the AWS SDK handles request signing
This is a focused fix in auth-controller.ts only, avoiding the risky
model-auth-runtime-shared.ts changes that could re-introduce the
fake-apiKey injection pattern on ECS (see prior regressions #49891,
#50699, #54274).
Fixes#62995
* fix(pi-auth): clean up aws-sdk sentinel fallback
* docs(changelog): note aws-sdk Bedrock auth fix
---------
Co-authored-by: Vincent Koc <vincentkoc@ieee.org>
Peter Steinberger