In bytedance/deer-flow v2.0-m1-rc1, changes to `config.yaml` (notably `max_tokens`) do not reliably apply while the gateway is running. The gateway initializes `request.app.state.config` once at startup, passes that object through run context and runtime/agent factories, and therefore executes subsequent runs against old settings until the process is restarted.
What ChangedIn bytedance/deer-flow v2.0-m1-rc1, changes to `config.yaml` (notably `max_tokens`) do not reliably apply while the gateway is running. The gateway initializes `request.app.state.config` once at startup, passes that object through run context and runtime/agent factories, and therefore executes subsequent runs against old settings until the process is restarted.
Why It MattersOperators using the local Docker stack can change config files expecting immediate effect, but many runs continue with old startup values (for example an 8192 token cap) until a gateway restart, which makes behavior inconsistent between consecutive runs and can cause unexpected truncation-driven retries and extra cost. The technical root is that `app.state.config` is set once at startup and then threaded through `get_config`, worker runtime context, and lead-agent creation, bypassing reload checks in `get_app_config()` on active request/run paths. This is especially important for users relying on dynamic tuning of model output limits or runtime backends during long Ultra workflows, and it should be watched for whether the product moves to true hot-reload semantics or introduces an explicit, clearly surfaced restart-required boundary for affected fields.
Final score 84Confidence 951 evidence itemAppConfigconfig.yamlgatewayrequest.app.state.configget_app_configrun contextruntime componentsmax_tokensv2.0-m1-rc1
An open issue reports that when browser-use triggers a CDP screenshot action, the returned raw base64 PNG is persisted in Claude Code conversation context and then resent on each turn, causing every subsequent message to fail with `400 invalid_request_error: Could not process image`. The failure is effectively unrecoverable within the same session and blocks normal interaction until the user opens a new session.
What ChangedAn open issue reports that when browser-use triggers a CDP screenshot action, the returned raw base64 PNG is persisted in Claude Code conversation context and then resent on each turn, causing every subsequent message to fail with `400 invalid_request_error: Could not process image`. The failure is effectively unrecoverable within the same session and blocks normal interaction until the user opens a new session.
Why It MattersUsers running browser automation through Claude Code can have an active session become unusable after a single screenshot step, so they lose continuity and must start over, which is disruptive for interactive agent workflows. The technical trigger is likely replaying a large or malformed base64 image blob from `Page.captureScreenshot` in every request, which repeatedly trips Anthropic validation; teams should watch whether upcoming changes normalize image handling (media_type, size/compression, and conditional return) before assuming screenshot-based flows are safe at scale.
A 21-day telemetry thread from 192 sessions (21,089 tool calls) shows that Serena symbol lookups with file paths (`find_symbol`/`get_symbols_overview`) are frequently followed by an immediate `Read` of the same file path in-session: 102 of 554 calls (18.4%), with a common pattern of `find_symbol(include_body=true)` plus `Read(offset/limit)` context slicing.
What ChangedA 21-day telemetry thread from 192 sessions (21,089 tool calls) shows that Serena symbol lookups with file paths (`find_symbol`/`get_symbols_overview`) are frequently followed by an immediate `Read` of the same file path in-session: 102 of 554 calls (18.4%), with a common pattern of `find_symbol(include_body=true)` plus `Read(offset/limit)` context slicing.
Why It MattersDevelopers using Serena in Claude Code will feel symbol navigation as a two-step process rather than a single lookup, so they can experience slower edit loops and extra context-fetching overhead when nearby lines are missing. The signal is actionable because 18.4% of resolved symbol queries fallback to same-file reads, usually with `offset/limit`, so teams should validate whether richer symbol-context output lowers this fallback rate without increasing response size or noise.
Final score 82Confidence 931 evidence itemmcp__serena__find_symbolmcp__serena__get_symbols_overviewClaude Code Readinclude_bodyoffset_limit
The pull request changes `firstLine()` in `internal/watcher` so that when a subject is capped at `maxLen=200`, trimming now backs up to the nearest valid UTF-8 boundary instead of slicing at an arbitrary byte offset. This keeps `watcher_events.subject` rows validly encoded for Slack/ntfy/webhook paths and prevents strict UTF-8 consumers from failing on truncated multi-byte characters.
What ChangedThe pull request changes `firstLine()` in `internal/watcher` so that when a subject is capped at `maxLen=200`, trimming now backs up to the nearest valid UTF-8 boundary instead of slicing at an arbitrary byte offset. This keeps `watcher_events.subject` rows validly encoded for Slack/ntfy/webhook paths and prevents strict UTF-8 consumers from failing on truncated multi-byte characters.
Why It MattersOperators and integration developers using watcher consumers can avoid notification pipelines stalling on a single bad subject row, because strict UTF-8 decoders (such as the Python bridge) no longer fail when reading oversized multi-byte subjects and the queue can continue advancing. Technically, the fix removes malformed trailing bytes at 200-byte truncation points and validates behavior for Cyrillic, em-dash, and emoji boundaries; continue tracking whether other event fields or upstream producers can still emit non-UTF8 data and whether retry logic should route failures to a dead-letter path instead of endless reprocessing.
Final score 82Confidence 971 evidence itemfirstLine()watcher_events.subjectinternal/watcher/webhook.goutf8.ValidStringPython bridge
The PR fixes a backend regression where `normalize_input` rebuilt every inbound dict as a plain `HumanMessage` and dropped `additional_kwargs`, `id`, and `name`, which caused uploaded files to vanish from the active turn and appear as `(empty)` to the model. It now delegates conversion to `convert_to_messages`, preserving message roles and metadata (including `additional_kwargs.files`) at the gateway boundary so uploads and message identity survive into runtime processing.
What ChangedThe PR fixes a backend regression where `normalize_input` rebuilt every inbound dict as a plain `HumanMessage` and dropped `additional_kwargs`, `id`, and `name`, which caused uploaded files to vanish from the active turn and appear as `(empty)` to the model. It now delegates conversion to `convert_to_messages`, preserving message roles and metadata (including `additional_kwargs.files`) at the gateway boundary so uploads and message identity survive into runtime processing.
Why It MattersChat users and operators who upload files in a turn will now see those files remain attached and rendered for the current message instead of disappearing after submission, so file-dependent interactions keep using the intended context and avoid silent fallback behavior. This is achieved by routing inbound message normalization through the same conversion path LangGraph uses, and the next watch items are client-side payload compatibility with supported roles, schema drift in `additional_kwargs`, and stability of message-ID deduplication when optimistic and persisted messages are reconciled.
Final score 82Confidence 981 evidence itemnormalize_inputconvert_to_messagesadditional_kwargs.filesBaseMessageDynamicContextMiddlewareUploadsMiddleware
The PR fixes a correctness bug in google/adk-go where `/api/run` and `/api/run` SSE handlers decoded `RunAgentRequest.StateDelta` but did not persist it, so resumed or contextual runs could execute with unchanged session state. It adds a central `applyStateDeltaIfPresent` path that appends a `system` `state_delta` event through `sessionService.AppendEvent` before invoking the runner, and then uses that merged state in `Get()`, ensuring runtime state now updates as documented.
What ChangedThe PR fixes a correctness bug in google/adk-go where `/api/run` and `/api/run` SSE handlers decoded `RunAgentRequest.StateDelta` but did not persist it, so resumed or contextual runs could execute with unchanged session state. It adds a central `applyStateDeltaIfPresent` path that appends a `system` `state_delta` event through `sessionService.AppendEvent` before invoking the runner, and then uses that merged state in `Get()`, ensuring runtime state now updates as documented.
Why It MattersDevelopers and operators using ADK `/api/run` (including resume/continuation flows) now get the state they send in `stateDelta` applied before execution, so agent runs can continue with intended updated context instead of silently ignoring updates and behaving inconsistently across turns. This is implemented by creating a `state_delta` session event before runner startup in both REST and SSE handlers, then merging that state via normal session retrieval. Continue watching for error handling around event append failures, concurrent `stateDelta` updates to the same session, and whether any clients depend on the previously ignored behavior.
Final score 82Confidence 981 evidence itemgoogle/adk-goRunAgentRequest.StateDeltasessionService.AppendEventRunHandlerRunSSEHandlerEventActions.state_deltaapplyStateDeltaIfPresent
This PR changes how agent prompts are injected into generated launch commands by removing bash-only heredoc transport (`$(cat <<...)`) and switching to shell-quoted single-argument argv prompts or `printf '%s\n' '<prompt>' | <agent>` stdin piping, fixing prompt launch failures in fish and improving shell compatibility.
What ChangedThis PR changes how agent prompts are injected into generated launch commands by removing bash-only heredoc transport (`$(cat <<...)`) and switching to shell-quoted single-argument argv prompts or `printf '%s\n' '<prompt>' | <agent>` stdin piping, fixing prompt launch failures in fish and improving shell compatibility.
Why It MattersOperators and users running Superset agent launches in fish (or mixed shell workflows) can now execute prompts without the launch command failing on heredoc-rejected syntax, reducing broken interactive runs and the need to switch shells or retry prompts; continue watching for quoting regressions with embedded single quotes and complex multiline prompt payloads across bash/zsh/fish compatibility.
Final score 82Confidence 971 evidence itemfish_shellheredoc_prompt_transportagent_launch_commandshell_quoted_argvprintf_stdin_pipeshared_host_service
Fixed a TOCTOU race in `AgentManager::get_or_create_agent` where concurrent first-time requests for the same session could each build an `Agent` and trigger duplicate MCP extension loading. The change adds per-session serialization so only one creator runs the slow initialization path while other callers reuse the cached agent.
What ChangedFixed a TOCTOU race in `AgentManager::get_or_create_agent` where concurrent first-time requests for the same session could each build an `Agent` and trigger duplicate MCP extension loading. The change adds per-session serialization so only one creator runs the slow initialization path while other callers reuse the cached agent.
Why It MattersOperators and developers using the same session for concurrent start/resume flows will see MCP extensions initialized once instead of repeatedly, so startup no longer causes bursty duplicate MCP traffic and session readiness becomes more stable. The implementation scopes locking to a single session, and now the remaining work is to watch for lock contention under very high concurrent access to one session and verify session removal always clears mutex metadata so long-running deployments do not accumulate per-session lock state.
Final score 81Confidence 961 evidence itemAgentManagerget_or_create_agentsessions RwLocksession-id keyed Arc<Mutex>Agent::with_configload_extensions_from_session
ADK-Go fixes a broken round trip in Vertex AI session handling by preserving `FunctionCall` and `FunctionResponse` IDs when converting session events from Vertex AI back into `genai.Content`, so IDs written during save are no longer dropped on read.
What ChangedADK-Go fixes a broken round trip in Vertex AI session handling by preserving `FunctionCall` and `FunctionResponse` IDs when converting session events from Vertex AI back into `genai.Content`, so IDs written during save are no longer dropped on read.
Why It MattersAgents using Vertex AI session history in ADK-Go will keep tool calls correctly paired with their tool responses across turns, which reduces the chance of mis-associating results during later workflow steps. By restoring this deserialization behavior, history replay becomes structurally consistent with how IDs are stored; teams should watch for older session records that may still contain missing IDs and monitor any mismatches in cross-language handling with ADK-Python clients.
Final score 81Confidence 981 evidence itemaiplatformToGenaiContentcreateAiplatformpbContentgenai.FunctionCall.IDgenai.FunctionResponse.IDVertex AI sessionsgoogle/adk-go
`AcpDetector.batchCheckCliAvailability` on POSIX was changed so a slow PATH scan no longer makes all built-in ACP CLIs appear missing. The batch `command -v` probe timeout was raised from 3s to 8s, and on batch timeout it now falls back to parallel per-CLI checks with a 3s limit each, isolating slow lookups from other tool detections.
What Changed`AcpDetector.batchCheckCliAvailability` on POSIX was changed so a slow PATH scan no longer makes all built-in ACP CLIs appear missing. The batch `command -v` probe timeout was raised from 3s to 8s, and on batch timeout it now falls back to parallel per-CLI checks with a 3s limit each, isolating slow lookups from other tool detections.
Why It MattersDevelopers and operators using AionUi in WSL, Docker, or slow-mounted PATH environments should see far fewer startup cases where all assistants disappear from the picker, so installed CLIs remain usable without manual troubleshooting. Technically, the patch changes POSIX detection from an all-or-nothing batch failure model to batch-first with parallel per-CLI recovery, so a single delayed lookup cannot mask the availability of others; continue watching startup latency when many CLIs are absent and whether fallback logs still clearly separate true missing tools from slow-path delays.
Final score 81Confidence 941 evidence itemAcpDetector.batchCheckCliAvailabilityPOSIX_BATCH_TIMEOUT_MSPOSIX_PER_CLI_TIMEOUT_MScommand -vPromise.allSettled
The PR fixes a policy bypass in browser-use URL checks by enforcing domain rules for special schemes: when `allowed_domains` or `prohibited_domains` is configured, `data:` URLs are denied and `blob:` URLs are validated against the embedded origin checks so they cannot slip past existing domain allowlist/prohibitlist logic.
What ChangedThe PR fixes a policy bypass in browser-use URL checks by enforcing domain rules for special schemes: when `allowed_domains` or `prohibited_domains` is configured, `data:` URLs are denied and `blob:` URLs are validated against the embedded origin checks so they cannot slip past existing domain allowlist/prohibitlist logic.
Why It MattersOperators running browser-use with domain restrictions will stop seeing blocked or prohibited targets reached through `data:` or crafted `blob:` links, so policy-controlled automation stays within governance boundaries instead of silently leaking traffic. The change is implemented by hard-blocking `data:` URLs when either allow/prohibit domain rules are enabled and by resolving `blob:` URLs to their embedded origin before reuse of existing checks; continue monitoring for false positives with legitimate `blob:` URL workflows and for any new scheme-based bypasses as URL parsing paths evolve.
DeepSeek-Reasonix now routes `path_access` approval decisions through the web dashboard end-to-end, so the model’s file-access request no longer leaves the session in a hang state when permission is needed outside the sandbox.
What ChangedDeepSeek-Reasonix now routes `path_access` approval decisions through the web dashboard end-to-end, so the model’s file-access request no longer leaves the session in a hang state when permission is needed outside the sandbox.
Why It MattersWeb-dashboard users and operators can now resolve out-of-sandbox file-access prompts directly in the browser instead of being stuck with a blank dashboard and a frozen assistant loop, so approval-driven workflows continue without requiring a TUI workaround. The change also surfaces pending path prompts across reconnects, which should cut operational interruptions, but teams should continue watching reconnect consistency during an active modal, correctness of allow-prefix/sandbox-root display values, and whether permission decisions are applied atomically when multiple pending prompts occur.
Final score 81Confidence 961 evidence itempendingPathPathModalPathConfirmDashboardContext.resolvePathConfirm/api/modal/resolvemodal-upmodal-downActiveModal
The notifier now suppresses repeated `running→waiting` [EVENT] alerts for the same child when its output has not changed, addressing a case where one dormant child emitted 47 identical wait notifications in 15.5 hours. A new dedup key `(child_id, to_status, last_output_hash)` is applied with a 2-hour TTL, while the legacy 90-second `(from, to)` dedup remains for callers that cannot provide output hash context.
What ChangedThe notifier now suppresses repeated `running→waiting` [EVENT] alerts for the same child when its output has not changed, addressing a case where one dormant child emitted 47 identical wait notifications in 15.5 hours. A new dedup key `(child_id, to_status, last_output_hash)` is applied with a 2-hour TTL, while the legacy 90-second `(from, to)` dedup remains for callers that cannot provide output hash context.
Why It MattersOperators of agent-deck conductor sessions will see much less notification noise from stalled children, so monitoring and automation avoid repeated useless context rechecks while still receiving real progress updates and periodic liveness confirmation. Technically, deduplication now keys on child + target status + output hash for 2 hours, then re-emits once per TTL to avoid silent stalls, and falls back to the prior 90-second window when callers lack `Instance`-based hash data. Watch next: any path still missing `LastOutputHash` may continue to rely on looser dedup and could reintroduce alert noise under replay or non-instance flows.
Final score 81Confidence 961 evidence itemagent-deckstatus-transition notifiertransitionNotifyRecordLastOutputHashlast_output_hash2-hour TTL90-second dedup window
This PR extends the prior Claude rebind fix to Codex and Gemini by extracting rebind helper paths and adding new state-db writers that atomically persist each rebind’s new session UUID and detected timestamp into `state.db`, replacing in-memory-only updates that left stale IDs behind.
What ChangedThis PR extends the prior Claude rebind fix to Codex and Gemini by extracting rebind helper paths and adding new state-db writers that atomically persist each rebind’s new session UUID and detected timestamp into `state.db`, replacing in-memory-only updates that left stale IDs behind.
Why It MattersOperators and users running multi-process Codex/Gemini workflows will see fewer runaway rebind loops and less session-state thrash after hook events, because stale UUIDs are no longer left in `state.db` while in-memory state advances. The system now converges on one current binding and cross-process consumers read the updated session mapping immediately; continue watching for any remaining code paths that bypass these new helper-backed writes and for sqlite contention behavior under high-frequency rebind traffic.
Final score 81Confidence 961 evidence itemagent-deckUpdateHookStatusCodexSessionIDGeminiSessionIDstate.dbstatedb.WriteCodexSessionBindingstatedb.WriteGeminiSessionBinding
The PR introduces a capability-gate flow for Agent Skills: skills can declare required capabilities via frontmatter, and a new validator enforces those requirements through SkillManager and discovery so unusable skills can be filtered or blocked before execution.
What ChangedThe PR introduces a capability-gate flow for Agent Skills: skills can declare required capabilities via frontmatter, and a new validator enforces those requirements through SkillManager and discovery so unusable skills can be filtered or blocked before execution.
Why It MattersOperators and AI workflow builders can catch missing skill prerequisites before a run starts, so agents are less likely to hit unexpected mid-execution failures when a required external dependency is absent. The change also exposes a clear diagnostic path via the doctor command and enforcement modes, which should reduce troubleshooting time for flaky skill setups. After rollout, watch for migration gaps in existing skills without the new requires_* metadata, false positives/negatives in dependency detection, and policy configuration errors in SKILL_CAPABILITY_ENFORCEMENT (especially when switching to strict mode).
Final score 81Confidence 961 evidence itemPraisonAI Agent SkillsSkillRequirementsCapabilityValidatorSkillManagerSKILL_CAPABILITY_ENFORCEMENTCLI doctor
This PR adds a required `Workflow Progress Trail` rule to core AI-DLC workflow guidance so each assistant reply in an active session ends with a one-line status breadcrumb showing stage and unit progress, visibility of active/skipped/pending steps, and no-guess placeholders for unknown construction counts.
What ChangedThis PR adds a required `Workflow Progress Trail` rule to core AI-DLC workflow guidance so each assistant reply in an active session ends with a one-line status breadcrumb showing stage and unit progress, visibility of active/skipped/pending steps, and no-guess placeholders for unknown construction counts.
Why It MattersIn active AI-DLC projects, users and operators will now get a real-time, in-chat progress marker on every assistant turn, so they can understand what is currently running and what is next without opening state files or interrupting workflow to regain context. This is implemented by deriving the trail from `aidlc-state.md` and forcing the emission step in every response-producing stage, while limiting verbosity with a collapsed/unit-aware display that still expands the current unit and stage. Watch for breadcrumb accuracy when state files update concurrently with responses, and for any custom integrations that skip the mandatory emission blocks because missing trails would reintroduce context-switch failures.
Final score 81Confidence 961 evidence itemcore-workflow.mdAI-DLC Progress trailaidlc-state.mdexecution-plan.mdInceptionConstruction Units
The gateway `cancel_run` flow was fixed to avoid spurious 409 conflicts when two cancellation requests hit the same active run. It now rechecks the run state after a failed `cancel()` and treats already-interrupted or already-removed runs as a successful no-op (202), while still returning 409 for truly completed/error/timeout terminal states.
What ChangedThe gateway `cancel_run` flow was fixed to avoid spurious 409 conflicts when two cancellation requests hit the same active run. It now rechecks the run state after a failed `cancel()` and treats already-interrupted or already-removed runs as a successful no-op (202), while still returning 409 for truly completed/error/timeout terminal states.
Why It MattersClients and operators that retry cancel requests (for example orchestration systems and monitoring scripts) will see fewer false cancellation failures because duplicate cancels on already-interrupted runs now return 202 and do not block workflows. The change fixes a race in the lock/lock-free get path, and teams should watch for edge cases where terminal state transitions are re-read incorrectly under cleanup timing so a completed run is never incorrectly accepted as idempotently interrupted.
Final score 81Confidence 961 evidence itemdeer-flowcancel_rungatewayrun statusinterruptedHTTP 202HTTP 409
In DeerFlow PR #3039, the run worker now buffers streamed `AIMessageChunk` data by stable message ID and, on `RunStatus.interrupted`, writes it as `llm.ai.partial` journal output so a stopped run can return partial assistant text instead of an empty run record after refresh.
What ChangedIn DeerFlow PR #3039, the run worker now buffers streamed `AIMessageChunk` data by stable message ID and, on `RunStatus.interrupted`, writes it as `llm.ai.partial` journal output so a stopped run can return partial assistant text instead of an empty run record after refresh.
Why It MattersDevelopers and operators reloading a run after an explicit stop will now see the partial assistant response instead of a blank/partial conversation, which preserves diagnostic context and reduces the chance of having to replay or discard interrupted sessions. The mechanism buffers chunked output in the worker and emits `llm.ai.partial` events during the interrupt finalization path, with completed-message ID tracking to suppress duplicates if normal completion happened just before stop. Watch next for partial-buffer cleanup and dedup behavior under rapid stop/retry cycles or high-concurrency streaming, since stale buffers or race windows could otherwise reintroduce duplicated or missing fragments.
Final score 81Confidence 961 evidence itemRunJournalAIMessageChunkpartial_ai_contentrecord_partial_ai_messageRunStatus.interruptedon_llm_endlist_messages_by_run
The PR changes Superset’s generated agent launch command path so argv-based prompt launches are wrapped in `bash -c '...'` with portable quoting, fixing fish shell parse failures (`<<` being treated as invalid redirection) while leaving stdin-with-file launches unwrapped with POSIX `<` redirection.
What ChangedThe PR changes Superset’s generated agent launch command path so argv-based prompt launches are wrapped in `bash -c '...'` with portable quoting, fixing fish shell parse failures (`<<` being treated as invalid redirection) while leaving stdin-with-file launches unwrapped with POSIX `<` redirection.
Why It MattersDevelopers and operators starting Superset AI agents from fish or other non-bash shells should be able to launch reliably instead of being blocked by immediate shell errors, so day-to-day agent workflows become less brittle and less likely to fail before any actual task work begins. The change enforces a shell-agnostic execution path for heredoc/cmd-substitution commands while keeping stdin-with-file launches untouched via `<` for cleaner compatibility, and should be monitored for any quoting edge cases or unexpected behavior in unusual prompt content and additional shell environments.
The PR narrows a restart bypass so `--session-id` (both `--session-id <uuid>` and `--session-id=<uuid>`) parsed from the launch command becomes authoritative, preventing disk-based session-ID discovery from overriding explicit IDs when multiple agent-deck sessions share one project directory.
What ChangedThe PR narrows a restart bypass so `--session-id` (both `--session-id <uuid>` and `--session-id=<uuid>`) parsed from the launch command becomes authoritative, preventing disk-based session-ID discovery from overriding explicit IDs when multiple agent-deck sessions share one project directory.
Why It MattersOperators running multiple agent-deck sessions in the same working directory will see fewer sessions get misbound or killed during restart cycles, because each session now keeps the session ID it was launched with. This reduces noisy duplicate-session sweeps and stabilizes long-running multi-instance workflows; because malformed or shell-dependent command forms are intentionally not supported, ongoing monitoring should focus on edge-case command syntaxes (quoted variables, shell expansions, non-UUID IDs) that could silently fall back to on-disk discovery and reintroduce wrong session reuse.
Final score 81Confidence 981 evidence itemensureClaudeSessionIDFromDiskForRestart--session-id flagdiscoverLatestClaudeJSONLdup-sweeperinstance.go
The PR changes chat control flow so user-entered text while a turn is running is treated as queued steering guidance instead of being blocked or discarded. Steering messages are now accepted in FIFO order and consumed at each model-iteration boundary, while command-like inputs (slash, shell-style, and memory commands) are rejected during busy turns.
ContributionIntroduces explicit mid-turn steering mode by keeping the input editable during a running turn, validating and queuing normal text as steer guidance, rejecting command-like inputs while busy, and switching from single pending steer storage to ordered multi-message queuing.
ImpactUsers running interactive turns can keep refining a task while it is executing, so instructions are less likely to be lost and workflows become smoother during long-running responses or tool calls. The system now buffers steer prompts in FIFO order and applies one queued steer at each loop boundary without interrupting the in-flight request; it also makes busy-mode UI behavior explicit, but operations should watch for queue buildup or latency if many steering messages arrive during extended busy periods.
The burst fixed a blocking behavior where path-access requests opened in TUI left the web dashboard blank and stalled execution, by wiring the web UI into the same approval gate as the terminal path-confirm flow. This gives operators a clear way to continue or block file-access escalation instead of waiting on an unanswered prompt.
ContributionImplemented a cross-interface path-approval bridge that connects web modal handling to the terminal/control plane, including a new `path` modal variant, active modal lifecycle signaling (`modal-up`/`modal-down`), resolver wiring in `App.tsx`, and API support for explicit path decisions. This changes path gate behavior from an implicit deadlock to an explicit user decision for path-bound tool calls.
ImpactWeb operators can now respond to model path-access prompts and unstick runs that previously froze with a blank dashboard modal, so workflows that request file operations outside the sandbox no longer hang unpredictably. The fix also synchronizes approval behavior across `run_command`, `path_access`, `plan`, `plan_checkpoint`, `plan_revision`, `choice`, and `edit_review`, reducing uncertainty during live intervention. Watch for modal state consistency during rapid multi-prompt bursts and reconnection windows, because mismatched pending-path state between UI and runtime remains the main scenario that could reintroduce stalls.
DeepSeek-Reasonix now routes `path_access` approval decisions through the web dashboard end-to-end, so the model’s file-access request no longer leaves the session in a hang state when permission is needed outside the sandbox.
ContributionImplemented the full TUI-to-web bridge for the path-approval gate by adding a `path` modal variant and payload (`path`, `intent`, `toolName`, `sandboxRoot`, `allowPrefix`), wiring dashboard-side modal lifecycle signaling, and exposing path resolution choices (`run_once`, `always_allow`, `deny`) through the same resolve API shape used by shell confirmation.
ImpactWeb-dashboard users and operators can now resolve out-of-sandbox file-access prompts directly in the browser instead of being stuck with a blank dashboard and a frozen assistant loop, so approval-driven workflows continue without requiring a TUI workaround. The change also surfaces pending path prompts across reconnects, which should cut operational interruptions, but teams should continue watching reconnect consistency during an active modal, correctness of allow-prefix/sandbox-root display values, and whether permission decisions are applied atomically when multiple pending prompts occur.
This PR’s main change is an async scheduler migration in the wrapper layer: it introduces an async-native periodic execution path and replaces global singleton runtime/tool state with context-local state so concurrent agent runs stay aligned with the same scheduling behavior.
ContributionIntroduces context-safe async execution by adding AsyncAgentScheduler and switching async runtime/tool context from process-wide globals to context-local storage, which is a concrete fix for concurrency-driven drift and state interference in multi-agent workflows.
ImpactOperators running multiple agents can execute periodic background tasks with fewer cross-agent surprises, so one agent’s tool or runtime context is less likely to leak into another and scheduled jobs are more stable in real concurrency. The technical change is the migration from global singletons to contextvars-backed context handling plus the new async scheduler API, and teams should monitor whether high-concurrency workloads still preserve intended schedule/retry behavior, whether any periodic jobs regress in timing, and whether users still on the deprecated `async_agent_scheduler` import complete migration before it becomes enforced.
The PR narrows a restart bypass so `--session-id` (both `--session-id <uuid>` and `--session-id=<uuid>`) parsed from the launch command becomes authoritative, preventing disk-based session-ID discovery from overriding explicit IDs when multiple agent-deck sessions share one project directory.
ContributionAdds a narrow parser in the restart path that extracts explicit `--session-id` values from `i.Command` and makes them the priority source of truth, while keeping existing disk-discovery fallback for sessions without explicit IDs, thus fixing collision-prone multi-session behavior in shared CWD setups.
ImpactOperators running multiple agent-deck sessions in the same working directory will see fewer sessions get misbound or killed during restart cycles, because each session now keeps the session ID it was launched with. This reduces noisy duplicate-session sweeps and stabilizes long-running multi-instance workflows; because malformed or shell-dependent command forms are intentionally not supported, ongoing monitoring should focus on edge-case command syntaxes (quoted variables, shell expansions, non-UUID IDs) that could silently fall back to on-disk discovery and reintroduce wrong session reuse.
OpenHands resolves issue #9255 by introducing a CLI-specific prompt path for CodeActAgent that removes browser-action guidance when running in CLI mode, steering the agent toward shell/file/Python alternatives instead of unsupported browsing actions.
ContributionCreated a runtime-aware prompt flow that swaps in CLI-specific system/user prompt templates and explicitly omits browser tool references, while directing agents to CLI-compatible workflows (bash, file inspection, Python image checks) when browsing is unavailable.
ImpactCLI users should see fewer failed steps and clearer instructions because agents will stop proposing browser actions that cannot execute in CLIRuntime, reducing user confusion and failed image parsing flows during text-to-command tasks. Technically, this aligns prompt content with available tools, so operators should watch for any remaining pathways where browser references leak through and any prompts that still rely on browsing behavior during runtime/config edge cases.
The PR adds a direct `praisonai serve ui-gateway` command so Pattern C users can start the integrated UI + gateway flow through a standardized CLI path instead of manual wiring, which materially lowers integration overhead when validating end-to-end deployments.
ContributionIntroduced a first-class Pattern C gateway entrypoint in both CLI and package API (`praisonai serve ui-gateway`, `run_integrated_gateway`, sync wrapper), creating a concrete deployment path for integrated UI-Gateway startup and reducing dependency on custom bootstrap glue.
ImpactDevelopers and operators who run PraisonAI integrations can now spin up the Pattern C UI-Gateway with one command, which can speed up local testing and deployment preparation while reducing setup mistakes from manual service wiring. The change also centralizes startup behavior through the main package API and configurable host/context style flow, so scripts can consistently control gateway launch settings; watch next for regressions in existing bootstrap scripts and whether this new entrypoint introduces behavioral drift in CI or custom deployment workflows.
This PR hardens the `website-to-hyperframes` skill by making quality checks enforceable and auditable rather than optional, following an audit and two rounds of enforcement edits. The primary change is a workflow shift to required evidence-first completion gates (notably a non-skippable Asset Audit and structured per-beat verification), which is intended to stop accepted outputs that skip required checks or misrepresent verification coverage.
ContributionIntroduced mandatory, non-skippable checks in the w2h workflow: a Step 3 Asset Audit gate requiring per-asset use/skip justification, a Step 5 structured evidence block format for each beat, and tighter enforcement so auto mode only bypasses user-preference gates while quality gates remain mandatory.
ImpactTeams running automated website-to-hyperframes conversions with sub-agents will get explicit fail/hold signals when required verification is incomplete, which reduces the chance of silently accepting outputs that reuse a tiny subset of assets or skip accessibility, audio, and motion checks. This is critical for operators and reviewers because it shifts from best-effort narration to auditable pass/fail behavior before content is treated as complete. The technical mechanism now ties completion to mandatory evidence and explicit disclosure of unverified items, so the next watch is whether the stricter gates cause false rejects from formatting/coverage gaps and whether any parallel sub-agent path still leaves stale snapshots unrefreshed after convergence.
This change adds `agy` as a supported agent backend in html-anything, introducing binary discovery via `ANTIGRAVITY_BIN`, CLI invocation with stream-json-compatible flags, and NDJSON parsing through the existing Claude parser path so Antigravity responses can be consumed by the convert flow.
ContributionAdded end-to-end agy integration into the agent system, including env/path-based `agy` binary detection, CLI argument alignment for JSON stream output, parser routing through the Claude branch, and model picker support for Gemini 2.5 variants.
ImpactDevelopers using html-anything can now plug Google Antigravity into existing agent-based conversion flows, so they can broaden model/tool choices without building a separate integration. The feature is implemented as a drop-in agent path from binary discovery to NDJSON ingestion, but teams should watch model-ID correctness and permission handling closely because placeholder model IDs and a `--dangerously-skip-permissions` execution mode are still in use and could cause misconfiguration or policy risk if left unchecked.
Introduced a docs-only Mobile Chat v2 PRD for `apps/mobile` that defines the first native mobile chat client plan, including session and mid-turn interaction behavior, transport assumptions via host-service APIs, push-notification scope, and a staged implementation roadmap with Storybook and Maestro validation gates.
ContributionEstablished a concrete, end-to-end technical and product blueprint for shipping native chat in Superset mobile (session lifecycle, composition/rendering, mid-turn prompts, navigation, transport, and notification behaviors), plus an 11-sprint execution plan and verification steps that align future code changes to one shared API and runtime contract.
ImpactMobile product and engineering teams now have a single implementation blueprint to build from, which reduces drift with existing host-service behavior and should shorten planning and integration cycles for the native chat feature; track whether follow-up implementation PRs preserve the defined session, approval, and streaming semantics when wiring relay auth, polling updates, and push token registration, because mismatches there would directly break chat continuity and user trust on mobile.
In v1.1.24, Emdash’s remote workflow stack was strengthened by adding SSH ProxyJump/ProxyCommand/ForwardAgent support and improving MaxSessions handling, which targets reliability of multi-hop SSH sessions.
ContributionImplemented SSH transport support for ProxyJump, ProxyCommand, and ForwardAgent plus a fix that surfaces an actionable MaxSessions state when SSH channels are exhausted, reducing silent failures in connected remote sessions.
ImpactRemote operators using Emdash for multi-hop or proxied SSH access can connect through their preferred jump-host flows and get early feedback when session limits are reached, so terminal workflows are less likely to drop unexpectedly during active work. Technically, this adds explicit proxy/jump-agent-forwarding behavior in SSH setup and a guardable channel-capacity UI path; monitor proxy configuration edge cases (e.g., mixed auth methods, unsupported targets) and whether MaxSessions thresholds are still under-reported on specific remoting stacks.
Goose v1.35.0 introduces an extensible hook framework around tool calls, adding both pre-tool and post-tool execution extension points and a PreToolUse denial hook so tool runs can be intercepted before action starts.
ContributionImplemented a configurable hook pipeline that lets users register code to run before and after each tool invocation, with a denial path that can block execution when custom policy checks fail.
ImpactDevelopers and operators can now prevent unsafe or undesired agent actions before they happen, reducing surprise side effects during automated tool workflows while retaining normal tool behavior when checks pass. The key follow-up is to monitor whether the new hook pipeline executes consistently across providers/tools, whether custom denial rules over-block legitimate requests, and whether hook failures cause tool-call reliability regressions.
Skills Manager now adds a new Skill Auto-Update setting flow that lets users schedule background checks for upstream skill updates (hourly, every 6 hours, or daily) and optionally apply detected updates automatically while the app is running.
ContributionImplemented a dedicated Settings entry for Skill Auto-Update that lets users define polling intervals and turn on automatic pulling/applying of upstream skill changes. In non-auto mode, the system continues to surface availability in the Library badge only, while auto mode removes the need for manual check/apply clicks.
ImpactOperators can keep agents' deployed skills fresher with minimal hands-on work, so long-running sessions are less likely to run against outdated capabilities. The feature adds periodic background polling plus an auto-apply path, so teams should monitor for unexpected behavior changes after automatic deployments and validate whether check frequency causes extra network load or synchronization delays in larger skill sets.
This change adds a new Agents surface to open-swe by porting reusable chat/diff/tool rendering components into `ui/src/components/agents/ported/`, introducing `/agents` and `/agents/$threadId` routes, and linking navigation so users can move directly into the Agents workspace with a “Back to Agents” path.
ContributionIntroduces a dedicated thread-based Agents interface in the frontend by reusing existing chat/diff/tool rendering components and wiring new routes and navigation to separate agent workflows from the dashboard UI.
ImpactDevelopers using open-swe can now manage agent threads in one place (`/agents`) instead of switching back to the dashboard, which should make inspection of chat, diff, and tool context more efficient during agent workflows; because the page currently depends on mock thread data, follow-up work should verify that connecting real LangGraph thread APIs does not introduce broken thread context, stale data rendering, or routing regressions.
Fixed a TOCTOU race in `AgentManager::get_or_create_agent` where concurrent first-time requests for the same session could each build an `Agent` and trigger duplicate MCP extension loading. The change adds per-session serialization so only one creator runs the slow initialization path while other callers reuse the cached agent.
ContributionIntroduced a session-scoped `Arc<Mutex<()>>` stored in a `HashMap` keyed by session id: after a cache miss, callers lock this mutex, re-check `sessions`, and only the first entrant performs `Agent::with_config` + `restore_provider_from_session` + `load_extensions_from_session`. This removes the race window and ensures one authoritative agent creation per session id, while unrelated sessions remain independent and unblocked.
ImpactOperators and developers using the same session for concurrent start/resume flows will see MCP extensions initialized once instead of repeatedly, so startup no longer causes bursty duplicate MCP traffic and session readiness becomes more stable. The implementation scopes locking to a single session, and now the remaining work is to watch for lock contention under very high concurrent access to one session and verify session removal always clears mutex metadata so long-running deployments do not accumulate per-session lock state.
Daytona announced an Agent Cloud service for AI agent workloads, emphasizing dedicated bare-metal sandbox execution and reporting strong scale momentum with 74% month-over-month growth and 850,000 daily runs.
ContributionIntroduced a production-oriented Agent Cloud platform centered on bare-metal sandbox isolation for deploying and evaluating AI agents, signaling a concrete infrastructure shift aimed at high-throughput agent operations.
ImpactTeams running AI agents now have a new managed path to execute workloads at high volume, which can reduce noisy-neighbor interference and improve predictability of large-scale agent operations (Daytona cites 850K daily runs), so operators should monitor whether latency and availability stay stable as traffic grows and whether evaluation feedback stays aligned with real user outcomes. If the new model scales as advertised, it could shorten the gap between experimentation and production usage, but rising bare-metal costs, provisioning failures, and RL eval quality drift are the main follow-up risks.
Daytona announced a dedicated Agent Cloud for AI agents, centered on bare-metal sandbox execution and positioned for RL evaluation workloads, with the company reporting 74% month-over-month growth and 850K daily runs as traction signals.
ContributionAdded a product direction shift from general agent execution toward a purpose-built agent runtime: a cloud platform that runs agents in bare-metal sandboxes and supports large-scale RL evaluation-style workloads.
ImpactDevelopers and operators using agent systems can use Daytona’s new Agent Cloud to run more of their inference/evaluation traffic in isolated, high-capacity sandboxes, which can reduce noisy-neighbor and stability issues as workloads scale, while the company-level growth figures suggest stronger demand pressure ahead. In practice, this means teams should watch for onboarding friction, reliability under the reported 850K daily-run scale, and whether isolation/security policies hold up as the service scales with 74% MoM growth.
ADR-128 refactors the default init bundle so `agents.all` is disabled and the baseline install drops from 98 agents/176 commands to 17 agents/16 commands, while making the package’s own 34 bundled `SKILL.md` files the canonical skill source.
ContributionIntroduced an init-bundle reduction and determinism fix: defaults were narrowed to reduce shipped surface area, ambiguous/unused commands were removed or promoted into `COMMANDS_MAP`, and skill resolution now uses the package-bundled `SKILL.md` set first to prevent stale per-user overrides from contaminating fresh installs.
ImpactNew users and operators who run the default `ruflo init` flow now get a much smaller, cleaner starting setup (17 agents, 16 commands) with less inherited state noise from prior installs, which directly reduces onboarding friction and lowers the chance of unexpected behavior during first-run initialization; the follow-up watch is whether downstream scripts that depended on auto-enabled agents or now-removed defaults fail silently. This is implemented by flipping the `agents.all` default to false, removing orphan command templates, and switching skill discovery to bundled `SKILL.md` files, so initialization behavior should become more predictable across machines and CI, but teams should validate custom automation that assumed the previous 98/176 defaults and plugin namespace overlaps remain compatible.
ADR-128 refactor in this commit burst changes `ruflo init` from loading nearly all agents by default to a curated default, moving to `agents.all = false` with an explicit `--all-agents` opt-in path, while bundling 29 canonical skills and tightening init-map validation to enforce source-of-truth command/agent packaging.
ContributionImplemented a concrete change in init packaging behavior: canonical skills are included in the CLI bundle, the default set of enabled agents was narrowed, and users now need an explicit opt-in flag to restore the full legacy agent set, with invariant checks added to catch unbound command or skill mappings.
ImpactDevelopers and operators running `ruflo init` will now receive a smaller default installation, which should make setup cleaner and reduce unnecessary agent footprint unless they explicitly request all agents, so existing automation that assumed an all-on default may become inconsistent. The underlying mechanism is the `agents.all` default flip to false plus map-based guardrails in CI (`smoke-init-bundle-invariants`) for orphan directories and overlap checks; continue to watch for scripts/docs that rely on implicit defaults and for any map gaps introduced for plugin-owned agents or removed init-template files.
This pull request proposes ADR-128, a bundled init refactor with a first phase that introduces an explicit `v3/@claude-flow/cli/.claude/skills/` source containing 29 skill directories. The change is intended to stop `ruflo init` from relying on fallback lookup into user-specific `~/.claude/skills/`, which has been the root cause of inconsistent skills on clean installs.
ContributionIntroduces a concrete source-of-truth fix for init templates: the init bundle will carry its own `skills` directory and be resolved from repo-owned paths, removing dependence on user home-directory `~/.claude/skills/` contents during initialization.
ImpactDevelopers creating new projects with `ruflo init` will get the same published skill set across machines, so agent behavior is less likely to drift due to stale or unrelated files in a local `~/.claude/skills/` folder. After this phase lands, the rollout should be watched for packaging and path-resolution correctness, because a missing or misresolved `.claude/skills` tree would silently restore inconsistent initialization semantics.
This PR changes Ruflo CLI init behavior by flipping the default agent policy from all-on to opt-in: `agents.all` is set to false and only curated category groups are loaded by default, reducing baseline agents from 98 to 17 (`core`, `consensus`, `swarm`, `sparc`, `testing`).
ContributionIntroduced an opt-in initialization model for agent loading by disabling default-all agent activation and introducing explicit category gating, which is a concrete configuration and runtime-behavior change for how the init bundle is assembled.
ImpactRuflo users running `init` now start with a smaller, cleaner default agent set, so normal startup and plugin workflows become lighter and less cluttered, but teams must verify any scripts or prompts that depended on previously default-loaded agents still resolve required agents explicitly. This change is implemented by flipping `agents.all` to false and restricting defaults to specific categories, so follow-up monitoring should focus on missing-agent regressions in existing automation, especially around plugin initialization paths and environment assumptions.
This PR adds an optional idle-timeout setting for agent-deck child sessions so they can be auto-stopped when no new tmux output appears for a configured duration, reducing dormant-worker accumulation from inactive sessions.
ContributionImplemented a concrete lifecycle control for idle sessions: new `agent-deck launch --idle-timeout` and `agent-deck session set <id> idle_timeout` controls, persisted timeout configuration (`instances.idle_timeout_secs` with default disabled), and a central watcher that enforces auto-stop when idle duration is exceeded, plus tests for timer reset, zero-timeout disable, runtime config updates, and CLI duration parsing.
ImpactOperators managing many agent-deck workers can reduce manual intervention, because silent child sessions are now automatically cleaned up after a configured idle period instead of consuming resources and attention indefinitely. The mechanism uses a central polling loop over per-session last-output timestamps and records `idle-timeout-expired` in auto-stop traces; keep watching for false positives on legitimate long-silent workloads, and verify timeout value propagation across config updates and migrations so real jobs are not prematurely stopped.
The notifier now suppresses repeated `running→waiting` [EVENT] alerts for the same child when its output has not changed, addressing a case where one dormant child emitted 47 identical wait notifications in 15.5 hours. A new dedup key `(child_id, to_status, last_output_hash)` is applied with a 2-hour TTL, while the legacy 90-second `(from, to)` dedup remains for callers that cannot provide output hash context.
ContributionAdded output-hash-based deduplication to the status-transition notifier with key `(child_id, to_status, last_output_hash)` to suppress non-progress duplicate wait events, implemented with `Instance.GetLastActivityTime()` as the hash source and persisted in `transitionNotifyRecord.OutputHash` for back-compat-compatible state migration. Added regression tests for same-status/same-hash suppression, output-change re-emit, status-change re-emit, TTL boundary re-emit as liveness ping, and legacy 90-second fallback behavior.
ImpactOperators of agent-deck conductor sessions will see much less notification noise from stalled children, so monitoring and automation avoid repeated useless context rechecks while still receiving real progress updates and periodic liveness confirmation. Technically, deduplication now keys on child + target status + output hash for 2 hours, then re-emits once per TTL to avoid silent stalls, and falls back to the prior 90-second window when callers lack `Instance`-based hash data. Watch next: any path still missing `LastOutputHash` may continue to rely on looser dedup and could reintroduce alert noise under replay or non-instance flows.
This PR extends the prior Claude rebind fix to Codex and Gemini by extracting rebind helper paths and adding new state-db writers that atomically persist each rebind’s new session UUID and detected timestamp into `state.db`, replacing in-memory-only updates that left stale IDs behind.
ContributionImplemented a concrete session-state correction for Codex and Gemini: hook-driven rebind/bind operations now persist session binding (`*_session_id` and `*_detected_at`) through dedicated helpers and atomic JSON field rewrites, preventing `state.db` from keeping an outdated session ID after rebinding.
ImpactOperators and users running multi-process Codex/Gemini workflows will see fewer runaway rebind loops and less session-state thrash after hook events, because stale UUIDs are no longer left in `state.db` while in-memory state advances. The system now converges on one current binding and cross-process consumers read the updated session mapping immediately; continue watching for any remaining code paths that bypass these new helper-backed writes and for sqlite contention behavior under high-frequency rebind traffic.
AWS describes a shift from static radiology queue rules to an AI-agent workflow that reprioritizes imaging studies using case context, radiologist specialization, current workload, fatigue, and complexity. The article reports that many hospitals currently see radiologists selecting easier, high-value studies first, which delays complex work and raises costs; the new workflow is positioned to reduce that operational skew. The signal is a concrete clinical workflow capability change rather than an infrastructure-only optimization.
ContributionIntroduces an adaptive worklist routing approach that uses AI agents to match studies to radiologists based on capability and operating state (expertise, load, fatigue, and case complexity), replacing rigid, rule-only assignment logic. The intended behavior change is to rebalance case selection so difficult studies are not systematically deferred.
ImpactRadiology teams can keep complex and high-priority imaging cases from being sidelined, so patients may receive timely reads for difficult cases while specialists spend less effort manually cherry-picking work and more time where they are most needed. This is implemented through an AgentCore-driven orchestration pattern over AWS health data and knowledge services (including HealthImaging, HealthLake, Guardrails, and Knowledge Bases), and should be tracked for whether the new prioritization remains clinically safe at peak load, whether it introduces prioritization drift over time, and whether override/audit signals stay visible enough for operators and compliance teams.
This PR proposes ADR-127 and defines a first-phase hardening change that adds static-contract smoke validation to GitHub agent and helper definitions, targeting unquoted interpolation of `github.event.comment.body` in shell snippets.
ContributionIntroduces a concrete security/correctness control by proposing contract-based smoke tests (based on `smoke-pre-bash-hook.mjs`) for `.claude/agents/github` and `.claude/helpers/github-*` scripts, so unsafe shell interpolation in comment-triggered automation can be detected before execution.
ImpactGitHub automation operators and repo maintainers using Ruflo’s PR/issue bots can reduce silently broken workflows and avoid flaky action runs by catching risky shell substitutions earlier in CI, instead of during live bot execution. The ADR links these checks to the existing pre-bash-hook style contracts for agent/helper files, but watch whether these checks are enforced as mandatory CI gates and whether other GitHub workflow paths still bypass the same protection.
LangChain, Deep Agents, and LangGraph are being positioned around a new agent-stream model that replaces plain token streaming with richer runtime events, enabling typed event payloads, scoped subscriptions, subagent visibility, and multimodal outputs during agent execution.
ContributionIntroduces a primary shift from plain token streaming to structured agent-stream primitives across the LangChain stack, so execution telemetry is emitted as typed, subscribable events that expose subagent activity and non-text outputs for application-level orchestration.
ImpactDevelopers building agent-powered applications can now get timely, structured updates about what an agent is doing (including subagent actions and non-text outputs), so dashboards and UIs can avoid generic token-only polling and become more resilient under multi-step workloads. This is implemented through typed event streams and scoped subscriptions in Deep Agents, LangChain, and LangGraph, with event-level visibility spanning subagents and multimodal outputs; it should improve operator visibility and easier production debugging. What to watch next: whether existing clients on old token-only streams migrate cleanly, whether new event schemas remain backward-compatible, and whether the richer stream surface adds extra front-end integration complexity at scale.
Agent.email launched a machine-oriented signup flow where an AI agent can request an inbox account via curl and then complete activation through a human one-time-password claim, enabling AI workloads to obtain dedicated mail accounts without going through a browser-only, human-centric sign-up path.
ContributionAdded a dedicated non-browser onboarding path for AI agents: curl-based signup plus human-verified OTP claim, creating a first-class email identity flow for agents instead of piggybacking on manual human account creation.
ImpactDevelopers of autonomous agents can now provision agent-owned email inboxes programmatically, which removes a key integration barrier for automated systems that need to send/receive mail as part of continuous workflows. The mechanism shifts onboarding to a scripted signup/claim flow with a human verification step, so teams can test whether end-to-end operator workflows become faster and less brittle; watch for platform and website-level blocks on non-human signup patterns, spam/abuse pressure from increased agent mail activity, and whether ownership verification remains strong under scale.
AWS published design guidance for building multi-tenant agentic applications on Amazon Bedrock AgentCore, outlining a reusable framework to handle SaaS-specific isolation, routing, and governance concerns in shared agent deployments.
ContributionDefines a concrete multi-tenant design pattern for AgentCore users: separation of tenant context and routing, secure boundaries, and operational controls that prevent customer workloads from interfering with each other in shared agent infrastructure.
ImpactSaaS operators building agent systems on Bedrock can reduce customer-visible outages and unpredictable behavior from cross-customer interference as they scale, because the guidance gives a clear blueprint for tenant-aware agent architecture. It further details AgentCore-oriented tenancy boundaries, policy enforcement, and lifecycle governance to implement, and teams should watch for execution gaps in identity propagation, resource limits, and observability that could still allow silent tenant bleed-through or noisy-neighbor effects.
The PR adds a `remote-agent-installer` module that automates the full lifecycle of remote Agent packages (agents, commands, skills, rules, and MCP) by checking for updates, downloading zip bundles, and installing/uninstalling modules automatically.
ContributionImplemented an end-to-end remote package management flow inside the extension: startup + scheduled version checks, HTTP(S) zip download with redirect and checksum validation, secure unpack/install/uninstall for five module types, install records with cooldown handling, failure retry with fatal-stop rules, and automatic cache refresh so installed modules become active immediately.
ImpactCoStrict users and extension operators can now roll out, update, or remove remote agent capabilities from a central source without manual file operations or editor restarts, reducing maintenance overhead and making feature delivery more consistent across environments. The update engine depends on scheduled background polling and lock-based concurrency, so next to watch are silently logged update failures, multi-window lock contention, and manifest/checksum/manifest-path integrity issues that could block or delay updates.
In bytedance/deer-flow v2.0-m1-rc1, changes to `config.yaml` (notably `max_tokens`) do not reliably apply while the gateway is running. The gateway initializes `request.app.state.config` once at startup, passes that object through run context and runtime/agent factories, and therefore executes subsequent runs against old settings until the process is restarted.
ContributionThe issue identifies a concrete behavior bug: the run path in the gateway binds to a startup `AppConfig` object instead of a freshly reloaded config, so updates to file-backed configuration are not consistently propagated to `RunContext`, runtime initialization, and downstream runtime components.
ImpactOperators using the local Docker stack can change config files expecting immediate effect, but many runs continue with old startup values (for example an 8192 token cap) until a gateway restart, which makes behavior inconsistent between consecutive runs and can cause unexpected truncation-driven retries and extra cost. The technical root is that `app.state.config` is set once at startup and then threaded through `get_config`, worker runtime context, and lead-agent creation, bypassing reload checks in `get_app_config()` on active request/run paths. This is especially important for users relying on dynamic tuning of model output limits or runtime backends during long Ultra workflows, and it should be watched for whether the product moves to true hot-reload semantics or introduces an explicit, clearly surfaced restart-required boundary for affected fields.
The PR fixes a backend regression where `normalize_input` rebuilt every inbound dict as a plain `HumanMessage` and dropped `additional_kwargs`, `id`, and `name`, which caused uploaded files to vanish from the active turn and appear as `(empty)` to the model. It now delegates conversion to `convert_to_messages`, preserving message roles and metadata (including `additional_kwargs.files`) at the gateway boundary so uploads and message identity survive into runtime processing.
ContributionReplaced the custom dict-to-message conversion in `backend/app/gateway/services.py` with LangChain’s `convert_to_messages`, which preserves `additional_kwargs` (including uploaded files), `id`, `name`, response metadata, and full role handling for human/AI/system/tool messages while leaving existing `BaseMessage` objects untouched.
ImpactChat users and operators who upload files in a turn will now see those files remain attached and rendered for the current message instead of disappearing after submission, so file-dependent interactions keep using the intended context and avoid silent fallback behavior. This is achieved by routing inbound message normalization through the same conversion path LangGraph uses, and the next watch items are client-side payload compatibility with supported roles, schema drift in `additional_kwargs`, and stability of message-ID deduplication when optimistic and persisted messages are reconciled.
This PR adds a new `wp-abilities-audit` skill that builds a structured audit document for a plugin’s REST surface and proposed Abilities API registrations in one pass. It standardizes how controllers, capability gates, and proposed abilities are represented so the output can be consumed by both humans and automation.
ContributionIntroduces a concrete workflow: controller enumeration plus capability-gate tracing, then emission of a canonical `audit-schema` containing required planning fields (`proposed_abilities`, `use_case_fit`, `side_effects`, `seed_data_needs`) that directly influence downstream implementation-shape selection.
ImpactPlugin integrators and automated reviewers can now generate a consistent REST capability audit before implementation, which reduces manual permission-checking errors and helps teams catch missing or unsafe Abilities API coverage earlier. The change adds explicit coupling from `side_effects` and related readiness fields to Shape-2/Shape-3 delegation choices, while preserving backward compatibility by warning (not failing) on legacy audits missing new fields; teams should still monitor how consistently these fields are populated and whether the dependent docs from PRs #44/#45 remain aligned so the intended automation signal is not drifted.
This change introduces a dedicated `cli/` package and command interface so html-anything can be run from the terminal, with `convert`, `templates`, `agents`, and `config` commands for scripted HTML generation and saved preferences. It centralizes the primary workflow into `html-anything convert` with support for markdown/text/csv/json input and terminal-friendly options (`-o`, `-d`, `-t`, `-a`) to control output and defaults.
ContributionThe primary technical change is the addition of a new command-line interface package in this repository, exposing `convert` and related commands so markdown-to-HTML conversion can be run in shell workflows with configurable templates, agent/model defaults, and automatic save behavior.
ImpactDevelopers and documentation operators can now generate styled HTML directly in terminal pipelines, which removes dependence on the web UI and enables batch or CI-driven conversions that previously required manual interaction. This is done by adding a new CLI entrypoint with conversion, template listing, agent discovery, and config-persistence commands; continue watching agent auto-detection in mixed PATH environments and default output path behavior, since wrong agent selection or unexpected output overwrites could break automated release/docs jobs.
The PR introduces a capability-gate flow for Agent Skills: skills can declare required capabilities via frontmatter, and a new validator enforces those requirements through SkillManager and discovery so unusable skills can be filtered or blocked before execution.
ContributionAdded a SkillRequirements model to declare skill dependency constraints, a CapabilityValidator with enforce levels (disabled, telemetry, warn, strict), and integration into the existing discovery/SkillManager path so agent flows can evaluate skill readiness consistently; also added CLI diagnostics to surface missing dependencies and migration/backward-compatible handling.
ImpactOperators and AI workflow builders can catch missing skill prerequisites before a run starts, so agents are less likely to hit unexpected mid-execution failures when a required external dependency is absent. The change also exposes a clear diagnostic path via the doctor command and enforcement modes, which should reduce troubleshooting time for flaky skill setups. After rollout, watch for migration gaps in existing skills without the new requires_* metadata, false positives/negatives in dependency detection, and policy configuration errors in SKILL_CAPABILITY_ENFORCEMENT (especially when switching to strict mode).
Added a `context.client` path so sanitized client metadata from the gateway can flow into `runtime.context` and agent dynamic context, enabling agents and skills to tailor output format decisions (such as artifact, CSV, and chart support) based on frontend capabilities and preferences.
ContributionImplemented client-aware response behavior by adding a sanitized `context.client` payload model and helper flow: gateway requests now redact-trim client metadata, forward it into runtime context, and inject a compact reminder into agent dynamic context so downstream agents/skills can switch output behavior per client.
ImpactDevelopers integrating custom frontends can make DeerFlow return outputs that match what their UI actually supports (for example, only sending chart or CSV-ready responses when available), reducing integration mismatches and manual post-processing; this should also lower the chance of degraded user-facing behavior in multi-client deployments. The change should be monitored for schema drift between frontend clients and runtime expectations, especially when fields are missing or inconsistent, and for any security or leakage issues around the trimmed context carried into prompts.
The PR introduces a new `praisonai.integration` host bootstrap path and rewires bundled `praisonaiui` apps to start through a common backend via `set_backend`, including making `praisonai dashboard --aiui` run with an in-process Pattern B host.
ContributionCreated a concrete integration mechanism that centralizes host and gateway initialization for the built-in UI apps, replacing fragmented startup wiring with a single reusable host setup so provider/session hooks can be shared consistently across entry points.
ImpactDevelopers and operators can now launch PraisonAI UI experiences (dashboard/chat/bot/realtime) through one shared host path, which should reduce setup mistakes and make integration behavior more consistent than juggling separate backend initialization per app; teams should watch whether real-world agentic workflows remain behaviorally stable with live API keys because smoke and openai-keyed end-to-end checks were still pending in this change set.
The commit burst includes a key usability fix: the TUI default mouse mode was changed to `?1007h` (alternate-scroll), so click/drag and right-click behavior is no longer consumed by Reasonix, while wheel scrolling still works; an escape hatch (`REASONIX_MOUSE_MODE=sgr|alternate-scroll|off`) was kept for edge terminals.
ContributionStops the UI from swallowing all mouse button events by default, which had made text selection and right-click context menus unreliable for many users across terminals.
ImpactTerminal users can now use normal text selection and right-click interactions again, so copying, editing, and selecting output in chat sessions no longer appears broken while wheel scrolling remains usable. The change is implemented by defaulting to alternate-scroll mode (`?1007h`) instead of `?1000h+?1006h`, with unsupported terminals expected to ignore the sequence and fall back to host scrollback; monitor reports from less common terminals to confirm no new interaction regressions in click/drag behavior.
v1.9.25’s primary change is a new web control path for MCP integrations, adding dedicated management endpoints and UI pages so teams can configure MCP tool connections from Agent Deck’s interface instead of through manual setup paths.
ContributionIntroduces concrete MCP operational capability by implementing web endpoints and a matching management UI, giving users an in-product way to create, update, and inspect MCP integration settings without manually patching backend/session configuration files.
ImpactTeams running AI coding agents can now manage MCP integrations directly in the web UI, reducing configuration downtime and lowering the risk of broken agent-tool setups from manual edits. This is delivered through newly added MCP management endpoints and UI surfaces in v1.9.25, so teams should watch for authorization coverage on new routes, validation behavior for config changes, and UI/backend state drift that could leave displayed settings out of sync with active sessions.
The PR removes the legacy LLM-driven `brv dream` root workflow and makes tool-mode the default execution path (`scan/finalize/undo/sessions/cancel`), while dropping root-only flags like `--force`, `--timeout`, and `--undo`. This is important because it removes a hidden daemon path that could silently mis-dispatch dream tasks in tool-mode setups without clear configuration context.
ContributionDeleted the legacy root-command LLM dispatch code path in CLI and daemon control flow (`src/oclif/commands/dream.ts`, `agent-process.ts`, and the dream branches in `brv-server.ts`) and rerouted operational flow through dedicated tool-mode command modules plus existing shared dream services. The concrete behavior change is a deterministic, explicit command model where dream actions are invoked only through listed subcommands, rather than through an implicit root command path.
ImpactTool-mode users and operators now get predictable CLI outcomes because `brv dream` no longer hides implicit dream dispatch behind a root command, so workflows are less likely to hit silent failures when providers are not configured and behavior is easier to reason about. The daemon no longer auto-schedules background dream runs, and agents trigger `brv dream scan` in controlled moments (for example after curate bursts or on session start), which should improve reliability but requires migration checks for any automation that still calls the removed root options or depends on the old auto-schedule behavior.
This PR adds a new `oh-my-issues` skill that automates issue backlog consolidation in claude-mem by clustering child issues into architectural plan masters, routing new bugs into those plans, and generating bundled PRs that close grouped issues together.
ContributionIntroduces a concrete issue-governance mechanism that standardizes how unconsolidated reports are reduced to root-cause plan-master tickets, how incoming reports are redirected to existing plans, and how related fixes are delivered through a single atomic bundled PR closure flow.
ImpactMaintainers can reduce manual issue triage overhead and avoid scattering fixes across ad hoc child tickets, because duplicate or related bugs are now funneled into shared plan-master workflows and can be closed in one controlled PR. The skill is triggered by user prompts for triage/consolidation tasks and encodes cluster, triage, and bundle behavior with locked redirect patterns plus drift checks (`graveyard`, `over-broad`, and `doc/issue drift`) so backlog structure is maintained. Continue watching whether clustering accuracy stays aligned to true root causes, whether plan states drift from issue metadata, and whether contributor environments consistently support the required `gh` CLI and CI command paths.
Added a new `plugin/skills/weekly-digests/SKILL.md` that generates a sequential ISO-week digest pipeline, writing one narrative chapter per week and preserving continuity via carry-forward context across the timeline.
ContributionIntroduced a concrete new skill path (`weekly-digests`) that outputs serial weekly chapters instead of a single monolithic timeline report, using a per-week sequential pipeline and carry-forward blocks to keep narrative arcs coherent across a project’s history.
ImpactProject teams using claude-mem can now review long-running work as a week-by-week story that stays coherent across time, which makes recurring retrospectives and operator handoffs easier without manually merging many timeline chunks. The implementation is sequential (one subagent per ISO week) and threads a carry-forward block forward with capped pruning (~350 words) so each chapter inherits prior context. Watch next for context truncation, context-propagation bugs across week boundaries, and whether reruns consistently reproduce identical file layouts.
This PR introduces a complete web-only skill-management flow for sessions by adding skill catalog/list and attach/detach endpoints and wiring them to a new Skills tab in the Web UI, replacing the previous stubbed screen.
ContributionImplemented browser-accessible project skill management by adding web handlers for skill catalog lookup and session-level attach/detach mutations, integrating them into a new Skills tab that mirrors existing TUI behavior and is test-covered in unit and end-to-end suites.
ImpactWeb users and operators can now manage session-scoped project skills from the browser, reducing workflow interruptions caused by unavailable UI controls and making skill setup/configuration for Claude/Gemini/Codex/Pi sessions directly operable in-session. The change also introduces source-qualified skill selection and stricter validation/error paths, so teams should continue watching unsupported-tool gating (e.g., shell sessions), session-not-found and not-attached error handling, and CI-e2e stability to catch regressions that could block UI skill actions.
This PR adds an experimental Skill subsystem so adk-go agents can discover skill directories, load skill instructions/resources, and execute skill-defined Python/Bash scripts through a dedicated SkillToolset.
ContributionIntroduced a first-class, file-based Skill model (Skill/Frontmatter/Resources/Script) plus a new toolset that exposes skill discovery, instruction/resource loading, and script execution actions, enabling agents to consume externally defined, specialized capability bundles at runtime without core logic changes.
ImpactDevelopers can now extend adk-go agents by dropping in a skill folder and invoking its scripts, which enables faster rollout of task-specific workflows (for example custom calculators or domain tools) without changing the agent implementation each time. The pull request wires this through the new SkillToolset and an UnsafeLocalCodeExecutor that runs Python/Bash locally via os/exec, so teams should watch script origin trust, command permissions, argument sanitization, and timeout/resource controls closely until sandboxed execution is introduced.
This PR changes WebFetch/curl-wget/inline-HTTP redirect messages to start with "redirected" and explicitly mark the action as a context-mode optimization, preventing a known Opus 4.6 behavior where the model misread the status as a network block and stopped trying retrieval tooling.
ContributionThe change updates user-facing tool status strings at the hook layer so the same fetch condition is framed as a redirect-to-context-mode path, not a sandbox/network block; this directly corrects the model’s tool-selection trigger and avoids the fallback branch that previously dropped back to training-only reasoning.
ImpactOperators of agentic research workflows should see more consistent behavior under redirect failures, because agents are less likely to abandon live fetches and answer from stale knowledge, which reduces incorrect or under-supported outputs in the same session. Technically, the PR flips the detection cue from a "blocked" message to a "redirected" message for WebFetch/curl-wget/inline-HTTP, preserving the tool-driven recovery path (`ctx_fetch_and_index`) in Opus-class agents; continue to watch how consistently other model versions/agents honor the new wording and whether DNS guidance is still missing in batch-style multi-URL failures.
Introduced a dedicated daily task evaluation pipeline in browser-use that runs task-card experiments via CLI and compares human-vs-agent behavior through preset suites (A–D).
ContributionAdded a concrete self-contained evaluation subsystem that standardizes browser-agent benchmarking: task-card definitions, preset-driven runs, multi-model executor selection (including OpenAI-compatible backends), optional continuous navigator replanning, and machine-readable comparison artifacts.
ImpactEvaluation teams and operators can now validate browser-agent behavior across multiple models in a repeatable, script-driven daily workflow instead of manual, inconsistent checks, so behavior drift is detected earlier before model/provider changes are promoted. The feature adds preset-driven daily experiments, optional continuous navigation, and exported history/conversation/summary data plus CSV/metric outputs to support direct comparisons, with frontier-style efficiency reporting. Continued monitoring should focus on navigator replan scheduling, task-card schema stability, and API/model routing defaults (especially Doubao via Volcengine Ark) for timeout, cost, and correctness regressions.
Version 0.13.9 fixes the new-conversation routing path so default agents are chosen more consistently from folder defaults and agent ordering, with the draft/retry/new-session entry points now using a clearer priority path to reduce wrong agent routing.
ContributionIntroduced a concrete behavior fix in conversation startup logic by redefining the priority rules for default-agent selection, making first-run, retry, and draft-resume sessions resolve to a stable default agent instead of ambiguous or inconsistent picks.
ImpactUsers opening new chats, retrying interactions, or reopening drafts in Codeg should see fewer surprises from being routed to the wrong default agent, which directly reduces confusion and repeated manual re-setup during day-to-day use. The update enforces a tighter default-agent priority chain in the conversation controller; monitor for regressions in nested-folder setups or large custom agent sets where priority ties could still produce unexpected routing.
OpenHands PR #14361 applies a security-only dependency update by bumping Poetry to version 2.3.4 to address CVE-2026-41140, aiming to remove a known vulnerability path in the project’s packaging/tooling workflow.
ContributionUpgrades the repository’s Poetry toolchain to 2.3.4 as a targeted mitigation for CVE-2026-41140, replacing the previously used vulnerable Poetry version and hardening dependency resolution/setup flows against that specific security issue.
ImpactDevelopers and operators running OpenHands builds are less exposed to a known security weakness during dependency installation and environment setup because the project now uses Poetry 2.3.4, the version tied to CVE-2026-41140 remediation; this should reduce risk of compromised build environments. Track whether the upgrade changes install behavior, lockfile handling, or CI image builds, since a version bump in packaging tooling can introduce compatibility regressions even when the security intent is clear.
Introduces a Goals feature so an agent can be assigned a long-term objective, persist it, and automatically continue across multiple turns until the objective is completed. The runtime now runs a post-turn check path (Runtime.OnTurnFinished -> MaybeContinue) and relaunches the agent when the session is idle, the queue is empty, and the goal is still active.
ContributionImplemented long-running, persistent goal orchestration for crush agents by adding goal state storage and a resumable turn loop: after each turn, the runtime evaluates session idleness and queue state, then conditionally re-invokes the agent with a continuation prompt; agents can mark completion through the update_goal tool.
ImpactTeams operating agents with crush can now assign a long-term goal and have the system continue work across multiple turns automatically, which reduces stalled workflows and manual prompting for multi-step tasks. Practically, this changes operator behavior by moving simple run-and-watch workflows into self-progressing sessions, while introducing new failure points to monitor: correctness of goal state transitions in the database, false positives in idle/queue detection that could cause repeated restarts, and reliability of goal completion signals so tasks do not run indefinitely.
Railway frames a strategic shift toward an agent-native platform, emphasizing own-metal data centers and framing AI coding agents as the primary workflow, while highlighting strong usage growth (3M users, 100K weekly sign-ups) and a reported move away from traditional PR-based development.
ContributionRepositioned the platform from PR-centric delivery to AI-agent-centric operations, with an explicit signal of own-metal infrastructure backing and product direction aligned to higher-volume, agent-driven software development and deployment.
ImpactDevelopers and operators on Railway are likely to move from review-heavy delivery cycles to faster agent-driven deployment loops, which can reduce handoff friction and increase iteration speed; the key follow-up is whether automation safeguards, access control, and infra scaling keep pace with rapid adoption, because mistakes by agents can now be promoted with less explicit human gating.
The review agent was reworked to prioritize high-confidence, defensible findings by retuning the reviewer prompt, adding stronger evidence checks, and removing confidence-threshold gating that no longer improved output quality.
ContributionImplemented a precision-tuned review workflow: the reviewer now uses web/wiki lookup and mandatory evidence-oriented prompting to suppress speculative and style-noise findings, and deprecated confidence-gated publishing paths (CONFIDENCE_ORDER, CONFIDENCE_THRESHOLD, confidence_threshold/min_confidence filters) that were shown to be low-signal.
ImpactDevelopers using Open SWE should get fewer false-positive findings, so they can spend less time reviewing noisy suggestions and more time fixing real defects; teams should now monitor recall for subtle bugs to ensure the stricter signal rules do not hide important lower-confidence issues. The change explicitly removed confidence-based publishing logic after an audit showed it did not reliably separate high-quality findings, replacing it with stricter prompt and archetype checks tied to concrete bug classes.
Deep Agents now adds an interpreter runtime so agents can execute code between tool calls, hold working state, and choose what information is passed back into context.
ContributionIntroduced an embedded interpreter layer in Deep Agents that enables executable, code-driven coordination between tools, replacing static handoff logic and making context inclusion explicit and programmable.
ImpactDevelopers building agent workflows can now reduce brittle prompt-based glue logic by writing and running small runtime code to coordinate tools, keep agent state, and control context flow, which can make multi-step automations more reliable and easier to adapt. This likely improves practical observability and maintainability of agent behavior, but teams should monitor execution safety controls, state consistency across tool steps, and added latency from interpreted execution in production loops.
Introduced the first operational in-conversation widget flow centered on a concrete `env_vars` widget, enabling agents to request credentials through transcript messages and let users submit values in-browser without sending secrets into the LLM prompt path.
ContributionImplemented the widget framework path in daemon, schema, MCP, and UI for `widget_request` messages, including the `env_vars` concrete widget and tool (`agor_widgets_request_env_vars`) that presents an inline form, validates requested variable names, submits via `/widgets/:id/submit`, and auto-resumes the waiting task flow with audit metadata instead of relying on external chat steps.
ImpactUsers and operators can now collect required API keys and other secrets inside the same conversation flow, so onboarding or permission steps complete faster and with less accidental exposure risk because sensitive values are kept out of agent-facing prompts. Technically, this introduces an in-conversation widget protocol (`widget_request`) plus a daemon UI/queue path (`env_vars`, `submit`, `dismiss`, auto-resume) that validates and applies env updates server-side and marks widget outcomes in task messages; continue watching for idempotent submit races, RBAC edge cases for non-admin collaborators, and any behavioral drift if deployments move beyond the current single-daemon assumptions.
The interview-me skill was changed so that any `CONFIDENCE` below ~70% must include a brief reason on the same line, explaining what remains unresolved. The pull request also updates the Step 1 guidance and example flow to show this rule in practice.
ContributionThis change adds an explicit behavior rule to the interview-me format: low-confidence answers must carry a same-line reason, and it updates the template/docs/test checklist to enforce that requirement.
ImpactUsers and operators of interview-me can immediately understand why a score is uncertain, reducing stalled interview turns and allowing them to provide the missing context on the first pass. The update introduces a thresholded output contract (~70%) and requires low-confidence lines to include unresolved-item reasons, which should improve collaboration and reduce back-and-forth time; verify that any downstream parsers or UIs consuming confidence values can still handle the richer line format without breaking.
OpenMonoAgent.ai added an option for the Agent to connect to an internal inference box over Local IP, with an optional local relay, so deployments in closed or tightly secured networks can route inference internally instead of requiring external connectivity.
ContributionIntroduces a new closed-network connectivity path by allowing Agent-to-Inference linking through Local IP, plus an optional relay mode for restricted segments.
ImpactDevelopers and operators can now run OpenMonoAgent in air-gapped or tightly controlled environments without exposing inference traffic to public endpoints, while still keeping agents functional; after merging, teams should watch relay behavior and local-network routing failures that could break inference flows under strict firewall and subnet rules. This change adds a network-access mode where the Agent targets an internal inference box by local IP and can fall back to a local relay when direct paths are constrained.
codeg v0.13.9 prioritizes a stable default-agent resolution path for the new conversation flow so retries, draft resumes, and new-session entry points follow a consistent selection order instead of falling back unpredictably.
ContributionIntroduced a concrete fix to the conversation initialization logic that deterministically resolves default agents using a defined priority across folder defaults, agent ordering, draft-tab context, and retry/new-session entry paths.
ImpactUsers starting, retrying, or resuming chats in codeg will hit the intended default assistant more consistently, so sessions are less likely to get derailed by unexpected agent switching. The updated resolution logic now applies a unified priority sequence for default-agent selection, reducing manual correction during frequent session transitions; teams should continue to watch for regressions in folders with dynamic agent overrides or frequently changing available-agent lists.
Pi v0.75.4 makes the CLI release and upgrade path supply-chain-hardened by shipping a generated `npm-shrinkwrap.json` and adding install-time checks for dependency pinning and lifecycle-script allowlists, with isolated npm/Bun smoke tests before release. These changes focus on preventing unintended transitive dependency drift during installation and updates.
ContributionImplemented a supply-chain hardening workflow for Pi CLI release/install operations: publish-time shrinkwrap generation, lockfile-change blocking, dependency pinning and lifecycle-script allowlist validation, self-update/install lifecycle script disabling where supported, and isolated npm+Bun install smoke tests.
ImpactDevelopers and operators using Pi CLI via npm or Bun now have a lower risk of unexpected upgrade breakage or supply-chain drift because installs are validated against a pinned dependency snapshot before and during release/update flows; follow-up to watch is whether the new lifecycle-script restrictions or lockfile checks introduce friction for legitimate custom install pipelines. This matters operationally because it reduces incidents where hidden transitive changes silently alter runtime behavior after upgrade, while still requiring teams to monitor legitimate extension/update scripts that may be blocked and any release failures caused by stricter lockfile enforcement.
A GitHub project is highlighted that uses AI agents to test distributed systems through claim-driven test definitions (instead of heavily setup-based cases), so tests are anchored to business invariants like idempotent operations, acknowledgment guarantees, and recovery behavior after partial failure.
ContributionIntroduces a testing approach where AI agents validate distributed-system behavior against explicit correctness claims, making test intent more resilient to drift than script/setup descriptions and enabling direct coverage of invariants such as idempotent posting and recovery guarantees.
ImpactTeams automating distributed-system checks with AI agents can keep test suites aligned with real failure behavior for longer, which helps operators catch regressions like duplicate processing or dropped acknowledgements before they reach production incidents.
The technical shift is that test generation is guided by falsifiable claims rather than only setup narratives; this is most useful where long-lived state makes traditional tests brittle, but it should still be monitored for false completion signals from agents, uneven coverage of critical invariants, and reproducibility of results under repeated failure scenarios.
ByteRover CLI 3.15.0 adds a `brv settings` workflow so users can change runtime parameters like agent pool size, per-project concurrency, and `llm.iterationBudgetMs` through `get/set/reset` commands, with values persisted in `<BRV_DATA_DIR>/settings.json` and used after `brv restart`.
ContributionIntroduces a first-class runtime configuration interface (`brv settings get/set/reset`) that replaces hard-coded/rebuild-required tuning of operational knobs with a persisted, user-editable settings store.
ImpactOperators and integrators can now adjust key runtime limits (agent concurrency and LLM iteration budget) through configuration commands instead of source edits or rebuilds, which makes ByteRover deployments easier to tune for different workloads and reduces friction when scaling or controlling task behavior. These settings are now written to `<BRV_DATA_DIR>/settings.json` and take effect after `brv restart`, while `--timeout` is effectively deprecated for this control path. Continue watching whether automation still depends on deprecated `--timeout` usage, and whether teams consistently apply `brv restart` after config changes so intended limits are actually enforced.
The lifecycle runtime now actively enters the `checkpoint` state when a checkpoint is reached, so existing mutation-guard logic is applied during pause windows and a user stop at checkpoint now performs a clean cancel instead of leaving execution state half-active.
ContributionImplemented a concrete lifecycle safety fix that activates the previously unreachable checkpoint path in engineering runs, enabling automatic high-risk mutation gating during checkpoint pauses and forcing clean termination on user stop to prevent dirty execution-state retention.
ImpactDuring engineering checkpoints, users and operators now get a real safety stop: risky tool actions are blocked while the run is paused, and pressing stop ends the workflow cleanly instead of leaving it mid-flight, so checkpointed sessions are less likely to drift into partial or unsafe execution; teams should keep watching for any checkpoint-triggering flows that still bypass the new transition and for legitimate actions that may now be overly delayed by gating. This is implemented by adding `recordCheckpointReached()` to flip `approved`/`executing` into `checkpoint`, then using existing `guardToolCall` behavior for mutation control, with a `lifecycle.cancel()` path in `App.tsx` when stop is chosen.
This PR removes the multi-context orchestrator RFC and nine probe scripts that evaluated a model-callable `spawn_subagent` topology after validation showed it caused severe spawn storms and heavy cost, while keeping fixed-name skill execution as the production path and retaining `registerSubagentTool` only as an explicit SDK surface.
ContributionRemoved the proposed default autonomous subagent topology by deleting the Multi-Context Orchestrator RFC and associated spawn-cost probe scripts, so the repository now documents and keeps only the bounded skill-invocation model (`run_skill` with fixed skill names) while preserving `registerSubagentTool` for explicit external SDK use.
ImpactOperators and integrators using DeepSeek-Reasonix can reduce unexpected token-cost explosions in long multi-step sessions, because the model-autonomous subagent spawning approach that was causing runaway investigation loops has been removed from the default design.
In benchmarking, model-driven `spawn_subagent` paths were significantly more expensive and produced repeated child-loop forking, while production behavior remained constrained to fixed-named skills (`/explore`, `/research`, `/review`, `/security-review`) through `run_skill(name=...)`; this reduces the risk of unbounded run-time growth. Watch for custom SDK integrations that re-enable free-form subagent spawning through `registerSubagentTool`, and monitor whether future prompt patterns reintroduce storm-like behavior.
This PR changes cc-connect so each completed `agent_message` round is emitted as `EventText` immediately, instead of being buffered as intermediate thinking and flushed only at the final round, making multi-round sessions visible in real time.
ContributionRemoved the `pendingMsgs` buffering path (`flushPendingAsThinking` / `flushPendingAsText`) from `session.go` and `appserver_session.go`, and changed `handleItemCompleted` so each `agent_message` writes output as `EventText` immediately; also removed a no-longer-needed `stateMu` around `emit()` in the AppServer path because emit is already concurrency-safe.
ImpactOperators and developers using Feishu with cc-connect now see each reasoning round appear as it happens, so they can monitor progress during long multi-step interactions instead of waiting to view only the final round. Technically, this PR replaces buffered-thinking rendering with direct per-round `EventText` emission in both backends, which should improve visibility and reduce confusion in iterative workflows; watch next for any ordering or concurrency edge cases in streaming under heavy multi-round prompts after removing the extra lock.
The burst’s main change is the introduction of a core bidirectional live execution path for agents through RunLive, enabling real-time streaming and session-aware agent flows instead of static, request-style execution.
ContributionIntroduces a unified core flow for live agent runs with streaming input/output and session lifecycle handling, including resumable sessions so operators can continue an interaction without starting over between turns.
ImpactDevelopers running real-time agent experiences can keep user interactions flowing without interruption, reducing the operational pain of dropped or repeated sessions during live AI usage. The update appears to replace parts of the execution path with a RunLive-based streaming model plus session state handling, so teams should monitor stream reconnection behavior, session state consistency, and cleanup/performance under long-running or high-frequency tool-calling sessions.
The desktop notification mapper now treats Claude Code session-lifetime hooks (`SessionStart`/`sessionStart`/`session_start` and `SessionEnd`/`sessionEnd`/`session_end`) as no-op status events (`null`) instead of mapping them to `Start` or `Stop`, removing a false status transition at session startup.
ContributionCorrected status translation in `apps/desktop/src/main/lib/notifications/map-event-type.ts` by returning `null` for six SessionStart/SessionEnd casings so session-lifetime events no longer map to `Start`/`Stop`; added targeted tests that specifically assert these cases must not change status, replacing a prior bug-encoding test.
ImpactDevelopers using Claude Code in terminal mode will stop seeing a fake “working” spinner and hidden review badge when the agent is merely starting up, so the pane status better reflects real workload and review visibility is preserved; continue monitoring whether newly introduced lifecycle event names or future mapper edits reintroduce misrouted status transitions. Technically, the desktop path is now aligned with host-service intent for session-lifetime events (idle state), while exit fallback logic still clears any leftover working/permission indicators on process termination, and test coverage now guards this regression boundary.
The burst mainly stabilizes how a new conversation picks its default agent, so folder and draft contexts now retain their intended agent instead of being overwritten by a previously focused tab or a globally stale/default one.
ContributionIntroduced explicit control for new-conversation agent selection (`inheritFromActive`, dedicated `onFallback` path, `setDraftAgentFromFallback`) and added hydration/race guards (`foldersHydrated`, freshness checks) so folder defaults and draft-confirmed agents are not silently replaced by unrelated tab context or stale data; sidebar default-agent selection is now limited to currently available agents with unavailable saved defaults marked clearly.
ImpactUsers who start new chats from folders or resume draft flows are now much less likely to be dropped into the wrong agent, which reduces misrouted conversations and the need for manual reconfiguration during day-to-day work. The implementation applies stricter selection rules at conversation startup and menu time (`foldersHydrated`, fresh agent list, unavailable-default markers), so invalid selections become visible instead of being silently persisted, but teams should continue watching startup hydration order and fallback-vs-user-confirmation precedence for edge-case race regressions.
OpenCove now installs missing supported local agent CLIs from within the desktop app and uses a single Agent settings list to manage provider ordering, default selection, install state, and model/environment configuration entry points.
ContributionIntroduces a controlled in-app installer for supported local agent CLI providers and centralizes their control in one provider list, replacing separate installation status UI and moving model/env edits to a per-provider Configure panel while keeping Settings as the single source of provider state.
ImpactUsers can fix missing local agent setups from OpenCove Settings instead of running manual package-manager commands, which shortens onboarding and recovery when agents are not installed or misconfigured. This is implemented by moving install execution into the main process via validated `agent:install-provider` IPC and refreshing executable availability after installation, so the UI can stay aligned with actual runtime availability; watch for regressions if fixed provider-to-package mappings lag new/updated providers or if install-success refresh misses edge cases, as those would leave users seeing stale availability or wrong config state.
Emdash v1.1.22 changes how GitHub credentials are selected and applied during connection, which matters because users must complete this step before most repository and task operations can run. Making the auth path more reliable reduces setup friction and helps prevent stalled workflows during onboarding and reconnects.
ContributionRefines the GitHub authentication flow by improving auth-source selection logic during connection, a concrete behavior change that targets failures where users were left in broken or confusing login states before they could proceed with workspace work.
ImpactDevelopers can connect and reconnect GitHub projects in Emdash with fewer blocked sessions, so they can get back to code review, task, and terminal actions faster; watch authentication retry rates after SSO or organization-policy changes, since those edge cases can still surface different token-scope or permission errors. The change appears to tighten connection orchestration around auth source handling, so teams should monitor mixed-account setups and token-rotation scenarios for hidden fallbacks or silent permission mismatches.
Google I/O 2026 coverage identifies Gemini 3.5 Flash as a newly announced Gemini release, indicating an expanded model option in Google’s AI stack.
ContributionIntroduced a new Gemini model variant (Gemini 3.5 Flash) as the headline update, adding a new selectable option in Google’s model lineup for downstream adopters.
ImpactDevelopers and product teams now have a newly announced model tier to evaluate, so they can plan integration and benchmarking around it once availability details are published; until then, they should monitor rollout timing, performance and quality characteristics, and any API or quota changes before shifting production traffic. The announcement currently provides no technical specs, so this should be treated as a naming-level signal that needs validation with later documentation and benchmarks.
Introduces a per-user persisted file storage limit driven by `fileConfig.storageLimit`, with runtime quota checks added to uploads, generated file outputs, agent artifacts, and skill-file paths so writes are blocked when a user exceeds their assigned storage budget.
ContributionImplemented a concrete per-user storage-governance feature in the API layer: usage lookup and quota-check helpers were added, wired into upload and file-output code paths, and integrated with shared config/schema validation and config docs so configured limits are consistently enforced.
ImpactOperators and developers can now prevent one user from consuming most of the shared LibreChat storage through uploads and generated/agent/skill artifacts, because operations are now rejected once configured per-user quotas are exceeded and users receive explicit quota errors. The checks are based on positive-byte `File` and authored `SkillFile` usage within tenant scope, with replacement-flow exclusions handled explicitly; follow-up risk to watch is that avatar/profile-image flows remain outside this ledger model and could still bypass the new quota behavior.
Added a new `databricks-genie-bedrock-agentcore` skill in ai-dev-kit to provide an out-of-box, governed path for Amazon Bedrock agents to access Databricks Genie through AgentCore Gateway as an MCP tool, while avoiding data movement into Bedrock Knowledge Bases and preserving Unity Catalog governance end-to-end. This matters because it turns a previously undocumented multi-service connection into a reusable, supported integration for enterprise analytics agents.
ContributionIntroduced a first-class integration skill that standardizes Genie-to-Bedrock AgentCore onboarding with explicit governance-aware behavior: users get template-driven deployment assets, identity-flow guidance, and clear caveats (including no-governance-in-M2M labeling), replacing brittle custom glue code and undocumented setup.
ImpactEnterprise teams can now ship Bedrock-agent workflows that answer Databricks-governed analytics queries without copying data into separate Knowledge Bases or rebuilding the integration logic themselves, so controlled AI assistants can be delivered faster with policy continuity. The key mechanism is a packaged MCP-tool skill with AgentCore Gateway wiring, identity mode handling (OBO-first), and IaC paths, but operators should watch for AWS AgentCore registry/schema changes, OAuth redirect-flow setup regressions, and any accidental use of M2M where user-level governance is expected.
A design doc proposes a reusable in-conversation widget primitive for agents: a typed MCP widget request path that shows inline UI in the transcript and stores widget state on message rows, with an initial env-var widget to collect onboarding secrets (e.g., HUBSPOT_API_KEY, GITHUB_TOKEN) while the model only receives sanitized status metadata.
ContributionDefines the concrete architecture for first-class in-conversation UI widgets: a dedicated message-type and event path, typed widget MCP tools, and a submit-to-daemon flow that reuses existing user credential persistence/encryption, so interactive onboarding and confirmations can be added as composable primitives instead of ad-hoc prompts.
ImpactAgents in Agor workflows can now ask for API keys and other sensitive inputs directly inside the chat stream, reducing operator/context switching during onboarding and preventing users from hand-copying secrets into places where the model can see them. Technically, the design routes secret values only through the browser→daemon submit path into encrypted user-store writes and keeps MCP/message channel data to `{names, status, scope}` only; the next step is validating the implementation so timeout policy, submitter-vs-session owner attribution, and widget state recovery are not regressions in production.
The key change in PR #1204 is upgrading `@github/copilot-sdk` from 0.2.2 to 0.3.0, which introduces per-session GitHub authentication so different sessions can carry different identities, quotas, and routing context.
ContributionAdds session-scoped authentication in the Copilot SDK by allowing each `createSession` call to pass a session-specific `gitHubToken`, decoupling identity and quota/model routing from a single client token.
ImpactTeams running multi-user or multi-project agent workloads in AGOR can avoid unexpected cross-account side effects, because one process can now host separate sessions for different GitHub users without reusing a single global identity. Practically, this comes from the v0.3.0 Copilot SDK package and should be monitored for regressions in clients that still assume one client-level token and for any stream/UI code that needs explicit handling of per-session behavior.
The PR introduces a unified slash-command surface in the ACP flow by moving slash command handling into a dedicated module and making `available_commands_update` return one list containing built-in, skill, and recipe commands. This gives clients a single source of truth with defined precedence for collisions, while reusing shared parsing paths for command arguments.
ContributionAdds first-class unified slash-command handling for built-ins, skills, and recipes by composing them into one discoverable command set and routing them through a shared parsing flow. It also implements concrete invocation semantics for skills and recipes (including placeholder and positional/flag arguments), reducing fragmented command surfaces and inconsistent behavior between listing and execution.
ImpactACP-aware clients and desktop users can now discover and invoke more slash commands consistently, so built-in, skill, and recipe commands are less likely to disappear or behave differently across surfaces; teams should verify that command visibility and parsing stay in sync as users add skills/recipes or change sessions/workspaces. Technically, the ACP command list now merges command sources with explicit precedence (`builtin > recipe > skill`) and shared argument parsing for skills and recipes, so command lookup and invocation paths are aligned, with close watch on collision overrides and stale-command cache behavior in clients.
This PR adds a required `Workflow Progress Trail` rule to core AI-DLC workflow guidance so each assistant reply in an active session ends with a one-line status breadcrumb showing stage and unit progress, visibility of active/skipped/pending steps, and no-guess placeholders for unknown construction counts.
ContributionIntroduced a mandatory workflow-output contract in `core-workflow.md` that appends a standardized breadcrumb line (`AI-DLC Progress: ...`) at the end of each user-facing assistant response, with uniform collapsing and active-next expansion rules across 13 response points (7 Inception stages, each Construction stage, and Build and Test).
ImpactIn active AI-DLC projects, users and operators will now get a real-time, in-chat progress marker on every assistant turn, so they can understand what is currently running and what is next without opening state files or interrupting workflow to regain context. This is implemented by deriving the trail from `aidlc-state.md` and forcing the emission step in every response-producing stage, while limiting verbosity with a collapsed/unit-aware display that still expands the current unit and stage. Watch for breadcrumb accuracy when state files update concurrently with responses, and for any custom integrations that skip the mandatory emission blocks because missing trails would reintroduce context-switch failures.