DEV Community: Ahab

Grok 4.6 vs 4.5: Migrate Long-Running Agents by Accepted-Task Cost

Ahab — Sat, 15 Aug 2026 01:18:52 +0000

Grok 4.6 vs 4.5: migrate long-running agents by accepted-task economics

Quick answer

SpaceXAI released grok-4.6 on August 12, 2026 as its new flagship for coding, agentic tasks, and knowledge work. It keeps Grok 4.5's 500,000-token context window and headline prices of $2 per million input tokens and $6 per million output tokens, while SpaceXAI reports stronger results on long-running agent evaluations.

Do not migrate on those headlines alone. Grok 4.6 raises cached-input pricing from $0.30 to $0.50 per million tokens below the 200K long-context threshold, and from $0.60 to $1 above it. A long coding session with a high cache-hit rate can therefore cost more even when input and output list prices look unchanged.

Run 4.5 and 4.6 on the same multi-step tasks, record context growth, retries, tool calls, human repair, and accepted results, then promote 4.6 only where the complete task economics improve. Treat API, Cursor, Grok Build, and GitHub Copilot availability as separate states.

Who this is for

This guide is for developers already routing production coding or research agents to Grok 4.5. It also helps teams evaluating Grok 4.6 through Cursor, Grok Build, or GitHub Copilot without confusing a partner announcement with verified access in every account and client.

If you are evaluating Grok for the first time, start with the Grok 4.5 coding-agent evaluation. This page focuses on the narrower migration decision: whether an existing, passing 4.5 route should move to 4.6.

What actually changed

Boundary	Grok 4.5	Grok 4.6	Migration implication
Context window	500K	500K	Capacity did not increase; measure how the agent uses it
Input / cached / output below 200K	$2 / $0.30 / $6	$2 / $0.50 / $6	Cached input is 66.7% more expensive
Input / cached / output at long-context rates	$4 / $0.60 / $12	$4 / $1 / $12	The whole request moves to the higher rate at the threshold
Modalities	Text and image to text	Text and image to text	Re-run image and structured-output contracts, not just code tasks
Agent capabilities	Function calling, structured output, reasoning	Function calling, structured output, reasoning	Tool compatibility still needs a canary
Published focus	Coding and agentic work	Longer-running agents and more ambitious interactive work	Test trajectory stability, not only first-answer quality

SpaceXAI reports that Grok 4.6 improves over 4.5 from 54% to 65.9% on DeepSWE 1.1, from 56.6% to 61.3% on FrontierCode 1.1 Extended, and from 47.1% to 57.5% on APEX-Agents. These are useful release signals, not proof for your repository: benchmark scores depend on the harness, task set, effort, and acceptance policy.

Use a paired long-running task pack

Choose six representative tasks that are long enough to expose planning and recovery behavior:

Fix a cross-file bug and add a regression test.
Migrate an API across at least five call sites without changing public behavior.
Complete a tool loop with one injected timeout and one recoverable invalid result.
Investigate a repository-wide performance issue and produce a verified patch.
Build a small interactive feature from a written brief and screenshot target.
Resume a stopped task from saved evidence without repeating completed work.

Pin the same repository commit, prompt, tools, sandbox, reasoning effort, timeout, and tool-call cap. Run at least three paired trials per task. Keep deterministic tests and screenshots outside the model so both candidates face the same acceptance gate.

Record more than tokens. A useful migration sheet includes first-pass acceptance, completed steps, repeated steps, tool failures, context size by turn, cached tokens, output tokens, wall time, and human repair minutes.

Calculate accepted-task economics

Use one cost record per trial:

model_cost = input_cost + cached_input_cost + output_and_reasoning_cost + tool_cost
recovery_cost = retry_model_cost + human_repair_minutes * internal_minute_rate
accepted_task_cost = (model_cost + recovery_cost) / accepted_tasks

Also plot prompt size by turn. Once a prompt reaches the 200K long-context threshold, SpaceXAI's pricing table applies the higher input, cached-input, and output rates to the entire request, not only the tokens above 200K. Context compaction that preserves acceptance can matter more than a small benchmark gain.

Do not mix Standard with Priority Processing during the model comparison. Priority is a separate 2x-priced service lane. First compare model versions on the same lane; test faster processing only after selecting the model.

A seven-gate migration workflow

1. Inventory every route

List direct API model IDs, moving aliases, Cursor settings, Grok Build workflows, Copilot policies, fallbacks, cached prompts, and scheduled jobs. Mark which routes can roll back independently.

2. Freeze the 4.5 baseline

Save the prompt revision, tool schema, harness version, acceptance tests, cost window, and three representative 4.5 traces. Without a fixed baseline, a simultaneous harness change can masquerade as a model improvement.

3. Prove the 4.6 API contract

Call the exact grok-4.6 model on a harmless structured-output task, a function call, an image input, and an intentional tool failure. Record the requested model, returned usage, region, status, and timestamp. Do not assume a picker label proves API behavior.

4. Run the paired pack

Alternate 4.5 and 4.6 trials to reduce time-of-day and service-load bias. Reject any comparison where effort, tool versions, timeout, or service lane differs.

5. Inspect trajectory growth

Flag repeated reads, unnecessary tool loops, premature compaction, lost constraints, and retries that rebuild context. A stronger first pass can still lose if it grows the transcript faster or requires more repair.

6. Verify partner availability separately

SpaceXAI says Grok 4.6 is available in Cursor, Grok Build, the API, and GitHub Copilot. At the time of this check, GitHub's supported-model and pricing references still listed Grok 4.5, while Cursor's changelog had not published a matching 4.6 entry. For each partner, record plan, admin policy, client version, picker visibility, successful invocation, and date. Documentation lag is an observation, not proof that a rollout failed.

7. Ramp with explicit rollback

Start with one low-risk task class, then 5%, 25%, and 100% only when acceptance, policy violations, wall time, and accepted-task cost stay within your predeclared budget. Keep 4.5 pinned as the rollback route until a representative production window passes.

Decision tree

Does 4.6 pass every safety and tool-contract canary?
  no  -> keep 4.5 and isolate the failed boundary
  yes -> does it improve accepted-task cost or a required quality gate?
           no  -> keep 4.5 for this route
           yes -> does the gain survive long-context and retry scenarios?
                    no  -> compact, narrow, or route only short tasks
                    yes -> ramp gradually with 4.5 rollback

Common mistakes

Calling pricing unchanged while ignoring the cached-input increase.
Comparing a 4.5 short task with a 4.6 long trajectory that crosses 200K.
Treating SpaceXAI's benchmark chart as repository-level acceptance evidence.
Mixing Standard and Priority lanes or changing the harness during the canary.
Treating API success as proof of Cursor or Copilot policy, picker, and invocation.
Removing the untrusted-repository sandbox gate because the new model self-tests more often.

Copyable decision record

date / owner / route:
baseline_model / candidate_model:
repository_commit / fixture_revision / harness_version:
reasoning_effort / service_lane / tool_versions:
first_pass_acceptance / final_acceptance:
context_by_turn / cached_input / output_and_reasoning:
retries / repeated_steps / tool_failures:
wall_time / human_repair_minutes:
accepted_task_cost_4_5 / accepted_task_cost_4_6:
partner_plan / policy / client / picker / invocation:
decision: hold | short-task-only | 5% | 25% | 100% | rollback
rollback_model / trigger:

FAQ

Is Grok 4.6 the same price as Grok 4.5?

Not exactly. Standard input and output prices match, but Grok 4.6's cached-input price is higher both below and above the 200K threshold. Calculate your actual prompt, cache, output, tool, and recovery mix.

Should every Grok 4.5 coding agent migrate?

No. Move only the task classes where paired evidence shows a required quality gain or better accepted-task economics. A stable 4.5 route can remain the better choice for short, high-cache workloads.

Is Grok 4.6 available in GitHub Copilot everywhere?

SpaceXAI announced availability on August 14 and said some Business and Enterprise organizations may need to enable the model. Because GitHub's reference pages still showed 4.5 when checked, verify the actual plan, policy, picker, client, and invocation before changing team instructions.

Sources

Gemini 3.7 Flash vs 3.6: Migrate by Accepted-Task Cost

Ahab — Fri, 14 Aug 2026 10:45:18 +0000

Gemini 3.7 Flash vs 3.6: migrate by accepted-task cost, not launch claims

Quick answer

Google released gemini-3.7-flash as a generally available Gemini API model on August 13, 2026. It has a 1,048,576-token input limit, up to 65,536 output tokens, and low, medium, and high thinking levels.

Do not migrate only because 3.7 is newer. Through December 31, 2026, Gemini 3.7 Flash and 3.6 Flash have the same list prices: $0.75 per million input tokens and $3.75 per million output tokens, including thinking tokens. Compare them on the same tasks and promote 3.7 only when its higher acceptance rate or lower retry cost wins.

API availability and GitHub Copilot availability are separate. The API model is GA; GitHub says Copilot access is rolling out gradually and Business or Enterprise administrators must enable a preview policy. A working API call does not prove the model is selectable in every Copilot client.

Who this is for

This guide is for developers already using Gemini 3.6 Flash or 3.5 Flash for coding agents, tool loops, or design-to-code work. It is also for teams deciding whether a visible “Gemini 3.7 Flash” picker entry is enough evidence to change a shared Copilot workflow.

For high-volume extraction, classification, or routing, also use the Gemini 3.6 Flash vs 3.5 Flash-Lite guide. Flash-Lite may still be the cheapest valid route.

What actually changed

Boundary	Confirmed behavior	Migration implication
Model identity	Stable ID is `gemini-3.7-flash`	Pin the exact ID during the canary; do not test through a moving alias
Context and output	1,048,576 input tokens; 65,536 output tokens	Large context is available, but still measure accepted work per token
Thinking	`low`, `medium`, and `high`; default is `medium`; `minimal` returns an error	Route effort explicitly and add a negative `minimal` test
Tools	Function calling, code execution, Computer Use preview, File Search, Search/Maps grounding, structured output, and URL context	Re-run every tool contract; model availability does not prove workflow parity
Pricing	3.7 and 3.6 share introductory Standard pricing through 2026-12-31	Token price alone cannot choose between them
Antigravity	3.7 is now the default model behind the Antigravity managed agent	Re-test agent behavior even if your agent ID is unchanged
Copilot	Gradual rollout across listed clients; organization policy may be required	Verify policy, picker, client, and returned behavior separately

Use a six-task accepted-result eval

Build one small, versioned fixture pack and run it unchanged against 3.6 and 3.7:

Repair a reproducible bug with a focused test.
Refactor three files without changing public behavior.
Complete a four-step function-calling loop with one recoverable tool error.
Implement a page from a screenshot and score visual parity.
Find a cross-file constraint inside a long repository context.
Produce schema-valid structured output with one adversarial input.

Fix the prompt, repository revision, tools, timeout, tool-call cap, and acceptance tests. Do not compare 3.6 medium with 3.7 high and call the difference a model win.

Record acceptance, retries, tokens, wall time, tool calls, policy violations, and human repair minutes. Then calculate:

accepted_task_cost = total_model_cost + retry_cost + human_repair_cost
acceptance_rate = accepted_runs / completed_runs

List price describes requests. Accepted-task cost describes whether the agent delivered usable work.

A seven-gate migration workflow

1. Inventory every route

List direct API calls, aliases, managed agents, batch jobs, cached prompts, Copilot clients, and fallbacks. Mark independent routes.

2. Remove incompatible request fields

When migrating from Gemini 3.5 Flash, Gemini 3 Flash Preview, or Gemini 3.1 Pro, remove temperature, top_p, top_k, and prefilled model turns. Gemini 3.6 already rejected those sampling fields, but verify your shared request builder rather than assuming it stayed clean.

3. Pin the exact model and lane

Use gemini-3.7-flash, not gemini-flash-latest, for the canary. Compare Standard with Standard. Batch and Flex are cheaper, while Priority costs more; mixing lanes hides whether the model or service tier changed the result.

4. Route thinking deliberately

Start with medium, the default. Try low for latency-sensitive drafting or triage and high for the hardest coding and tool tasks. Require the minimal request to fail, so a bad router cannot silently select an unsupported level.

5. Run the paired fixture pack

Alternate 3.6 and 3.7 runs. Keep outputs, tool traces, tests, screenshots, token usage, and rejection reasons. A benchmark headline is not repository evidence.

6. Verify Copilot as a separate state machine

For Copilot, record plan, policy, client version, picker visibility, invocation, and date. “Rolling out” means neither unavailable nor universal; capture the observed state when docs lag.

7. Ramp with rollback

Start with one low-risk route, then 5%, 25%, and 100% only if acceptance, latency, policy, and accepted-task cost stay inside your budget. Keep 3.6 as the explicit rollback target until a representative production window passes.

Common mistakes

Migrating because 3.7 and 3.6 have the same token price without measuring retries.
Sending minimal thinking even though 3.7 rejects it.
Comparing different thinking levels, service tiers, prompts, or tool versions.
Treating API GA as proof of Copilot policy or picker availability.
Removing the untrusted-repository sandbox gate because a newer model passes more tasks.

Copyable decision record

date / owner / decision:
routes_and_clients:
baseline_model / candidate_model:
exact_model_ids / service_tier:
fixture_revision / tool_versions:
thinking_levels_tested:
first_pass_acceptance / retry_rate:
input_tokens / output_plus_thinking_tokens:
wall_time / human_repair_minutes:
accepted_task_cost:
copilot_plan / policy / client / picker / invocation:
rollout_stage: hold | 5% | 25% | 100% | rollback
rollback_model / trigger:
recheck_before_2027_pricing:

FAQ

Is Gemini 3.7 Flash more expensive than 3.6 Flash?

Not during the introductory period. Their published Standard, Batch, Flex, Priority, and caching rates match through December 31, 2026. Prices double for both on January 1, 2027.

Should every Gemini 3.6 workload move to 3.7?

No. Keep a passing 3.6 route when migration risk exceeds the measured gain. Move tasks where 3.7 improves acceptance, retries, latency, or repair cost on your own fixtures.

Does Copilot support Gemini 3.7 Flash everywhere now?

GitHub announced a gradual rollout across several clients and plans. Business and Enterprise administrators must enable the preview policy. Verify the live client state before changing team instructions.

Sources

Gemini API release notes: https://ai.google.dev/gemini-api/docs/changelog
Gemini 3.7 Flash model page: https://ai.google.dev/gemini-api/docs/models/gemini-3.7-flash
Gemini 3.7 Flash changes and migration guide: https://ai.google.dev/gemini-api/docs/latest-model
Gemini Developer API pricing: https://ai.google.dev/gemini-api/docs/pricing
GitHub Copilot rollout announcement: https://github.blog/changelog/2026-08-13-gemini-3-7-flash-is-now-available-in-github-copilot/
GitHub Copilot supported-models reference: https://docs.github.com/en/copilot/reference/ai-models/supported-models

Qwen Code 0.21.11: Install Agent Plugins v1 Without Assuming Full Compatibility

Ahab — Thu, 13 Aug 2026 10:24:33 +0000

Qwen Code 0.21.11: install Agent Plugins v1 without assuming every capability works

Quick answer

Qwen Code 0.21.11 can install and link a standard Agent Plugins v1 package without converting its plugin.json, mcp.json, or SKILL.md files into qwen-extension.json.

That does not mean every component in an Agent Plugin runs in Qwen Code. The stable runtime loads direct-child Agent Skills plus stdio and Streamable HTTP MCP servers. It ignores commands, agents, hooks, context, settings, channels, apps, client namespaces, and legacy HTTP+SSE MCP entries.

Treat 0.21.11 as a portable-core release. Before enabling a third-party plugin broadly, prove the package is unchanged, inventory which capabilities actually load, test path and credential boundaries, verify persistent state, and keep a project-scoped rollback.

Who this is for

This guide is for extension authors and teams that want one portable plugin package to work in Qwen Code and other Agent Plugins clients. It is also for operators searching for “Qwen Code plugin not supported” after a package installs but a command, hook, agent, or MCP server is missing.

If you are migrating the same portable package into Codex, compare the Codex Agent Plugins rollout guide. The shared format reduces packaging work; each client still decides which capabilities it executes.

What changed in 0.21.11

The August 13 stable release adds native Agent Plugins v1 support. Qwen Code recognizes the canonical v1 schema, preserves the original package files, and uses the existing qwen extensions lifecycle for local directories, links, archives, Git repositories, archive URLs, and scoped npm packages.

The implementation deliberately matches a portable capability boundary rather than translating every client-specific feature. A root plugin.json for Agent Plugins takes precedence over other extension manifests. Unsupported schema versions fail explicitly; a missing or blank package version is represented internally as 1.0.0.

Agent Plugins v1 is a package format, not a marketplace integration. Native loading makes a package installable; it does not make every marketplace, command system, permission model, or client namespace portable.

Start with the real compatibility matrix

Package component	Qwen Code 0.21.11 behavior	Acceptance evidence
`skills//SKILL.md` as a direct child	Loaded when valid	Skill appears and can be invoked
Nested or malformed Skill	Skipped independently	Valid sibling still works
stdio MCP	Supported	Server connects with expected arguments and cwd
Streamable HTTP MCP	Supported with URL and credential controls	HTTPS or loopback HTTP connects safely
Legacy HTTP+SSE MCP	Skipped	Entry is absent; no silent transport substitution
Commands, agents, hooks	Ignored	None appears or executes
Context, settings, channels, apps, client namespaces	Ignored	No client-specific behavior is assumed
`allowed-tools` in a Skill	Parsed as metadata, not pre-approval	Tool still follows Qwen permission policy

This matrix is the contract. Do not label an ignored capability a failed installation, and do not label a successful installation full compatibility.

A seven-gate rollout workflow

1. Pin the client and package identity

Record qwen --version and require 0.21.11 or later. Pin the plugin source revision, archive checksum, or exact npm version. Review the root manifest before running any bundled server:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "my-agent-plugin",
  "version": "1.0.0"
}

Reject an unexpected schema, a changed source, or an identity collision. Installation consent is not a substitute for package provenance.

2. Start at project scope

Use a disposable repository and the narrowest existing scope:

qwen extensions install ./my-agent-plugin --scope project
qwen extensions list
qwen mcp list

For active development, qwen extensions link ./my-agent-plugin avoids copying the package. For a release canary, install the exact artifact users will receive. Do not begin with a global enablement.

3. Prove native loading did not rewrite the package

Hash the source files before installation. Confirm the installed or linked package retains plugin.json, mcp.json, SKILL.md, and server files byte-for-byte and does not gain a generated qwen-extension.json.

Also verify Qwen reports the origin as AgentPlugins. A converted Claude, Gemini, Qoder, or native Qwen extension follows a different compatibility path even if the visible feature looks similar.

4. Test supported and unsupported siblings together

Build a harmless fixture containing one valid direct-child Skill, one invalid or nested Skill, one stdio MCP server, and one unsupported command or hook. The pass condition is asymmetric:

the valid Skill and stdio server load;
the invalid Skill is isolated rather than disabling the valid sibling;
the command or hook remains unavailable;
allowed-tools does not silently bypass Qwen approval.

This catches the most dangerous rollout mistake: assuming an install success means every directory became executable.

5. Verify state and path containment

For stdio MCP, Qwen expands ${PLUGIN_ROOT} and ${PLUGIN_DATA} once in arguments, environment values, and cwd. Write a harmless sentinel into PLUGIN_DATA, update or reinstall the same plugin identity, and confirm the sentinel remains. Keep mutable state out of the read-only package root.

Then include a symlink or relative-path escape fixture. A manifest escape should reject the plugin; a component escape should disable only that component. No discovered, read, or executed path should leave the resolved plugin root.

6. Run the HTTP credential canaries

Remote MCP endpoints must use HTTPS; plain HTTP is allowed only for loopback. Test a local Streamable HTTP fixture first, then a controlled HTTPS endpoint. Require these outcomes:

unsafe remote HTTP is rejected;
client-owned headers cannot be overridden;
a configured credential or authorization header is not forwarded across a redirect;
one malformed MCP entry does not disable valid siblings.

Use synthetic tokens and local endpoints. A security canary should prove policy without risking a real secret.

7. Promote only the portable slice

Enable the plugin for one project, run representative Skill and MCP tasks, disable and re-enable it, then test update and uninstall. Promote to user scope only when the evidence matches the matrix.

If your product depends on commands, agents, hooks, context, channels, apps, or a marketplace, keep the client-specific package or adapter. The portable core and the Qwen-specific layer can coexist; pretending they are identical creates silent feature loss.

Common mistakes

Assuming the Agent Plugins logo means all clients execute the same components.
Converting the package manually even though 0.21.11 preserves the v1 files.
Testing only a happy-path Skill and never proving unsupported components stay inert.
Treating allowed-tools as a Qwen permission grant.
Putting mutable state under PLUGIN_ROOT instead of PLUGIN_DATA.
Allowing credentials to follow redirects during an MCP connectivity test.
Enabling globally before a project-scoped rollback passes.
Calling a marketplace listing part of the Agent Plugins v1 runtime contract.

For a broader permission-precedence test, use the Qwen Code workspace trust checklist. For MCP calls that may repeat after reconnects, pair this rollout with the Qwen MCP safe-replay checklist.

Copyable evidence record

date / owner / decision:
qwen_version / launcher:
plugin_name / version / source_revision_or_checksum:
install_scope: project | user
manifest_schema / origin:
source_hashes_match / generated_qwen_manifest_absent:
valid_skill / invalid_sibling_isolated:
stdio_mcp / streamable_http_mcp / legacy_sse_absent:
unsupported_commands_agents_hooks_absent:
allowed_tools_still_requires_policy:
plugin_data_persists_after_update:
path_escape_rejected:
unsafe_http_rejected / redirect_credential_stripped:
disable_enable_update_uninstall_results:
rollout: pass | hold | rollback
remaining_client_specific_layer:

FAQ

Can I install an Agent Plugin from GitHub or npm?

Yes. Qwen Code's existing extension sources include local paths, archives, Git repositories, archive URLs, and scoped npm packages. Pin the artifact and start at project scope.

Why did the plugin install but its command or agent is missing?

Because 0.21.11 intentionally loads only the portable Skill and supported MCP slice. Commands, agents, and hooks are ignored, not translated.

Does `allowed-tools` pre-approve tools in Qwen Code?

No. The field is recognized as metadata but does not grant pre-approved Qwen tools. Qwen's permission policy remains authoritative.

Is legacy SSE MCP automatically upgraded to Streamable HTTP?

No. Legacy HTTP+SSE entries are skipped. Use a supported stdio or Streamable HTTP definition and verify it explicitly.

Sources

Qwen Code 0.21.11 stable release: https://github.com/QwenLM/qwen-code/releases/tag/v0.21.11
Agent Plugins v1 user guide: https://github.com/QwenLM/qwen-code/blob/v0.21.11/docs/users/extension/agent-plugins.md
Qwen Code extensions guide: https://github.com/QwenLM/qwen-code/blob/v0.21.11/docs/users/extension/introduction.md
Native-support design and package boundary: https://github.com/QwenLM/qwen-code/blob/v0.21.11/docs/design/agent-plugins-v1-native-support.md
Merged implementation and reviewer test plan: https://github.com/QwenLM/qwen-code/pull/8834
Agent Plugins specification site: https://agent-plugins.org/

Claude Code 2.1.229: Keep Vertex and Bedrock Gateway Streams Alive

Ahab — Thu, 13 Aug 2026 01:21:02 +0000

Claude Code 2.1.229: keep Vertex and Bedrock gateway streams alive during long thinking

Quick answer

Claude Code 2.1.229 adds SSE keepalive pings to gateway streaming responses during long model-thinking pauses. Anthropic says the change prevents idle-timeout disconnects on Google Vertex AI and Amazon Bedrock upstreams.

Upgrade the Claude Code client that actually opens the provider stream, then replay one workload that previously failed with Stream idle timeout. Do not declare success because a short prompt works. Record a quiet interval longer than the old failure threshold and prove that the same request later resumes content and reaches a terminal result without a new request.

The patch is a liveness fix, not a universal timeout override. It does not repair expired credentials, provider quotas, a buffering reverse proxy, a total request timeout, or a broken network path.

Who this is for

This guide is for platform and developer-experience teams routing Claude Code through Vertex AI or Bedrock, directly or through an enterprise LLM gateway. It is especially useful when high-effort reasoning pauses long enough for a proxy, load balancer, or client watchdog to assume the stream is dead.

If your problem is runner isolation, credentials, hooks, or repository access, use the Claude Code self-hosted environment checklist. This page covers one narrower task: proving streaming liveness across a provider gateway.

What changed in 2.1.229

The August 12 UTC release states that gateway streaming responses now emit SSE keepalive pings during long thinking pauses, preventing idle-timeout disconnects on Vertex and Bedrock upstreams.

Claude Code's gateway documentation defines three supported API shapes: Anthropic Messages, Bedrock invoke-with-response-stream, and Vertex streamRawPredict. A gateway must preserve the provider-specific streaming request and required version or beta fields. Claude Code also sends X-Claude-Code-Session-Id, which lets operators correlate a session without reading prompt bodies.

That boundary matters. A keepalive can prove that a stream is still active only if every hop forwards it promptly. A proxy that buffers SSE, strips comments, closes quiet upstream connections earlier, or converts streaming into one buffered response can still fail.

Map the five-layer path first

Layer	What to record	Typical failure that 2.1.229 does not prove fixed
Claude Code client	Version, provider mode, model, effort	Old binary, wrong launcher, total API timeout
Local or enterprise gateway	API shape, route, session ID, buffering	SSE buffered or transformed
Load balancer / proxy	Idle limit, upstream and downstream logs	Connection closed before a ping passes
Vertex or Bedrock	Region, model ID, request ID, terminal status	Auth, quota, model access, provider error
User session	Prompt, start, quiet interval, completion	Retry mistaken for one continuous response

Do not change several layers at once. If you upgrade the client, raise proxy limits, change models, and move regions in one test, you cannot attribute the result.

A six-step verification workflow

1. Prove the active version and route

Run claude --version from the same launcher used by developers, CI, or the IDE. Require 2.1.229 or later. Inside the session, use /status to confirm Vertex or Bedrock and the intended model.

Inventory configuration names without printing secret values:

env | cut -d= -f1 | rg '^(CLAUDE_CODE_USE_(VERTEX|BEDROCK)|ANTHROPIC_(VERTEX|BEDROCK).*BASE_URL|CLOUD_ML_REGION|AWS_REGION|API_TIMEOUT_MS)$'

If a wrapper, IDE, container image, or self-hosted runner launches a different binary, upgrading your interactive shell proves nothing.

2. Freeze one known-failing canary

Choose a non-destructive task that previously produced a long quiet thinking interval. Pin the repository revision, model, effort, provider route, region, input, and gateway policy. Do not use a trivial prompt; it may never cross the old idle boundary.

Record the previous failure threshold from logs rather than guessing a new one. If no reproducible baseline exists, classify the result as a smoke test, not proof that the patch fixed your incident.

3. Correlate one session across hops

Capture the X-Claude-Code-Session-Id in gateway access logs and the provider request ID where available. Scrub authorization headers and prompt bodies. The evidence timeline should contain:

request accepted -> content/thinking activity -> quiet interval
-> keepalive activity observed at each controlled hop
-> content resumes -> terminal success

The release does not document a public ping interval or guarantee a particular textual payload. Test observed stream activity and continuity; do not hard-code an invented SSE comment.

4. Keep idle and total timeouts separate

API_TIMEOUT_MS is Claude Code's total API request timeout; the documented default is ten minutes. The 2.1.229 change addresses an idle stream during a request that is still alive. Raising the total timeout cannot make a proxy forward keepalives, while a healthy keepalive cannot authorize an unlimited total duration.

Retain your existing total request budget for the first canary. Change it only if the evidence shows the request is ending at that separate boundary.

5. Classify the result

Observation	Likely layer	Next action
Stream ends at the old idle threshold; gateway saw no keepalive	Client or gateway route	Verify the active 2.1.229+ binary and streaming API shape
Gateway saw activity, downstream client did not	Reverse proxy or buffering	Disable buffering for the SSE route and inspect downstream idle policy
Provider returns 401/403	Credentials or model access	Repair auth; do not label it an idle-timeout regression
Provider returns 429 or quota error	Capacity or limits	Follow provider retry guidance; do not extend timeouts blindly
One request exceeds the total timeout despite stream activity	Total request budget	Decide whether the workload or budget should change
Content resumes and completes with one request ID	Liveness path passes	Proceed to a bounded rollout

6. Roll out and retain rollback evidence

Start with one gateway route, one provider region, and a small user cohort. Compare idle disconnects, retries, duplicate tool calls, completion rate, and p95 request duration before and after. Keep the previous client package or image available for rollback, but do not downgrade if the old version reintroduces a confirmed reliability or security defect.

The Claude Code Action sandbox recovery guide shows the same release discipline for CI: prove the intended capability while keeping unrelated safety controls unchanged.

Common mistakes

Testing only a short prompt that never produces a quiet interval.
Increasing every timeout before locating the hop that closes the stream.
Treating a retry as continuation of the original request.
Logging tokens or full prompts to obtain correlation evidence.
Assuming a gateway supports streaming because non-streaming requests work.
Ignoring proxy buffering between the gateway and the Claude Code client.
Mixing a provider auth or quota failure with an idle-liveness failure.
Rolling out to all regions and models before one bounded route passes.

Copyable evidence record

date / owner / change:
claude_code_version / launcher:
provider: vertex | bedrock
model / effort / region:
gateway_api_shape / route:
proxy_idle_policy / total_api_timeout:
canary_commit / task / input_hash:
session_id / provider_request_id:
request_started_at:
last_content_before_quiet:
keepalive_seen_at_gateway / downstream:
content_resumed_at:
terminal_state / completed_at:
retry_or_new_request_seen: yes | no
pre_upgrade_result / post_upgrade_result:
rollout_decision: pass | hold | rollback
remaining_risk / next check:

FAQ

Should I just increase `API_TIMEOUT_MS`?

No. It controls total request duration. First prove whether an idle hop, total budget, authentication, quota, buffering, or network loss ended the request.

Does the fix apply to direct Anthropic API traffic?

The 2.1.229 release specifically describes gateway streaming responses and Vertex/Bedrock upstream idle timeouts. Do not generalize that statement to every transport without a canary.

How do I prove keepalive support without logging prompts?

Use the session correlation header, timestamps, byte or event activity, provider request IDs, and terminal status. Authorization values and prompt bodies are unnecessary.

Is a successful retry a pass?

No. The acceptance condition is one continuous logical request that survives the quiet interval and completes. A retry can duplicate cost or tool effects and must be recorded separately.

Sources

Claude Code 2.1.229 release: https://github.com/anthropics/claude-code/releases/tag/v2.1.229
Claude Code LLM gateway configuration: https://code.claude.com/docs/en/llm-gateway
Claude Code on Amazon Bedrock: https://code.claude.com/docs/en/amazon-bedrock
Claude Code on Google Vertex AI: https://code.claude.com/docs/en/google-vertex-ai
Claude Code environment variables: https://code.claude.com/docs/en/env-vars
Demand wording only — Claude Code stream-idle issue: https://github.com/anthropics/claude-code/issues/46987
Demand wording only — ping-aware watchdog proposal: https://github.com/anthropics/anthropic-sdk-typescript/issues/998

Chrome DevTools MCP 1.7: debug memory leaks without reading raw heap snapshots

Ahab — Wed, 12 Aug 2026 10:21:05 +0000

Chrome DevTools MCP 1.7: debug memory leaks without reading raw heap snapshots

Quick answer

Chrome DevTools MCP 1.7 gives AI coding agents a stronger memory-debugging path: a new object-details tool, native-context summaries and filters, an updated first-party memory-leak skill, and fixes that dispose heap-snapshot workers more reliably.

Do not hand a multi-gigabyte .heapsnapshot file to an LLM or ask it to guess from one snapshot. Use a three-snapshot protocol:

baseline -> repeat one suspected action 10 times -> target
         -> reverse/close the action -> final

Start with summaries, compare retained growth, isolate one suspicious class or native context, inspect representative objects and retaining paths, then close every loaded snapshot. A fix passes only when the same replay no longer exceeds a predeclared growth budget.

Who this is for

This guide is for developers using Codex, Claude Code, Cursor, Copilot, Gemini CLI, or another MCP-capable agent to diagnose browser or Node.js memory growth. It assumes you can reproduce one bounded action such as opening and closing a modal, navigating between views, reconnecting a stream, or processing one job.

If you first need the browser access and safety model, use the general Chrome DevTools MCP workflow. This page goes deeper on heap evidence and cleanup; it is not another console/network debugging overview.

What changed in 1.7

The August 10 release adds get_heapsnapshot_object_details, which lets an agent request known metadata for a specific heap node instead of reading a raw snapshot. Snapshot summaries now expose native contexts and their sizes, while get_heapsnapshot_details can filter objects by native context.

The bundled memory-leak skill now routes analysis through native MCP tools: summaries, snapshot comparison, class nodes, retaining paths, dominators, object details, duplicate strings, and category filters. It explicitly recommends capturing baseline, target, and final snapshots, repeating the suspected action ten times, and closing loaded snapshots afterward.

Version 1.7 also fixes two diagnostic-server cleanup paths: workers are disposed when a context tears down and when loading a missing or invalid snapshot fails. Those fixes reduce the chance that the debugger's own worker growth is confused with application growth, but they do not remove your responsibility to close snapshots or verify the active CLI and daemon versions.

Evidence ladder

Stage	Question	Smallest useful tool output	Stop condition
Summary	Did retained memory grow?	`get_heapsnapshot_summary` for three snapshots	No repeatable growth after cleanup
Comparison	Which classes accumulated?	`compare_heapsnapshots` summary, then one class diff	Growth is noise or expected cache
Context	Which page/frame/context owns it?	native-context sizes and filtered details	Wrong context or cross-page contamination
Object	What is one representative instance?	class nodes plus `get_heapsnapshot_object_details`	Object is expected and bounded
Retainer	Why is it still reachable?	retaining path, retainers, dominators, edges	Chain does not reach application code
Fix proof	Did the same replay improve?	fresh three-snapshot run and budget result	Budget still fails

Do not jump directly to a source-code change because a class name looks suspicious. Detached DOM nodes can be intentional caches; large strings can be generated output; framework objects may only be the visible end of a longer retaining chain.

A seven-step workflow

1. Pin the diagnostic boundary

Record the Chrome DevTools MCP version, agent client, browser or Node target, URL/process, commit, and exact reproduction. For this workflow, require 1.7.x on both sides when a daemon is used. The release adds a CLI warning for CLI/daemon version mismatch; treat that warning as a failed preflight.

Use a disposable profile or test account. Heap snapshots can contain application strings and object data, so keep snapshot paths out of source control and external prompts.

2. Define one action and a budget

Choose an action with a reverse operation:

open modal -> close modal
mount route -> navigate away
subscribe -> unsubscribe
start job -> finish and release job

Declare the loop count and pass rule before looking at the result. Example: ten open/close cycles must leave no more than two extra modal roots, no growing listener set, and less than 5 MB of retained growth after cleanup. The numbers are workload-specific; the important part is fixing them before diagnosis.

3. Capture baseline, target, and final

Stabilize the app, then capture baseline. Repeat the action ten times and capture target. Perform the reverse action, leave the app idle long enough for normal cleanup, and capture final.

Keep the same build, profile, page, input, and loop count. A reload between snapshots changes the experiment and makes the comparison hard to defend.

4. Compare summaries before drilling down

Run get_heapsnapshot_summary on all three snapshots. Compare total size, object counts, dominant classes, and native contexts. Then use compare_heapsnapshots for baseline-to-target and baseline-to-final.

Target growth alone does not prove a leak. The stronger signal is growth that remains in final after the reverse action. If a separate native context owns most of the increase, filter to it before asking for individual objects.

5. Follow one representative retaining chain

For a suspicious class, list instances with get_heapsnapshot_class_nodes. Pick a representative node from the final snapshot and request get_heapsnapshot_object_details. Then inspect retainers, retaining paths, dominators, and edges until the chain reaches application-owned state.

Use category filters to test specific hypotheses: objects retained by detached DOM nodes, event handlers, execution contexts, or console references. Use duplicate-string analysis only when string growth dominates the comparison.

6. Make the smallest ownership fix

Fix the first application-owned edge that should have been released: remove a listener, clear a timer, unsubscribe, bound a cache, delete a map entry, release an observer, or break a stale closure. Do not delete framework state merely because it dominates the heap.

Pair the change with a durable regression check where practical. The agent-instruction guide shows how to require evidence before edits, while the package-vetting workflow helps when the retaining path enters a new dependency.

7. Replay, close, and record

Restart from a clean process or page state and run the identical three-snapshot protocol. Compare the same metrics and class/context. Close every loaded snapshot with close_heapsnapshot, including snapshots from failed hypotheses.

Report pass only when the replay meets the predeclared budget. Otherwise report the remaining growth and next retaining-chain hypothesis.

Common mistakes

Feeding a raw .heapsnapshot file into the model and exhausting context.
Treating one large snapshot as proof of a leak.
Changing the action, loop count, profile, or build between baseline and replay.
Fixing a detached node without checking whether it is an intentional cache.
Comparing browser RSS to heap-retained size as if they were the same metric.
Forgetting that DevTools, extensions, console references, and the diagnostic server can retain objects.
Leaving snapshots loaded after the investigation.
Publishing a fix without a fresh, identical replay.

The WebMCP security checklist is useful when the inspected page exposes agent-callable actions; memory diagnosis does not relax write or data-access boundaries.

Copyable evidence record

date / owner / commit:
agent_client:
chrome_devtools_mcp_cli / daemon_version:
target_url_or_process:
snapshot_storage / retention:
suspected_action / reverse_action:
loop_count: 10
pass_budget:
baseline_summary:
target_summary:
final_summary:
largest_native_context_delta:
suspicious_class / representative_node_id:
retaining_path_to_application_code:
fix / regression_check:
replay_result: pass | fail
snapshots_closed: yes | no
remaining_risk / next hypothesis:

FAQ

Can an AI agent read the raw heap snapshot directly?

It should not. The first-party skill says raw heap snapshots are extremely large and recommends native MCP summary, comparison, class, object, and retaining-path tools instead.

Does target-snapshot growth prove a leak?

No. The action may intentionally allocate memory. Stronger evidence is retained growth that survives the reverse action in the final snapshot and points through a retaining chain to application-owned state.

Why inspect native contexts?

A browser process can contain multiple pages, frames, extensions, or execution contexts. Version 1.7 can summarize their sizes and filter details by context, helping the agent avoid blaming the wrong page.

Does 1.7 eliminate memory leaks in Chrome DevTools MCP itself?

No. It fixes specific worker-disposal paths. You still need matched versions, valid paths, bounded experiments, and explicit close_heapsnapshot cleanup.

Sources

Chrome DevTools MCP 1.7.0 release: https://github.com/ChromeDevTools/chrome-devtools-mcp/releases/tag/chrome-devtools-mcp-v1.7.0
Chrome DevTools MCP tools: https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/README.md
First-party memory-leak debugging skill: https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/skills/memory-leak-debugging/SKILL.md
Object-details tool: https://github.com/ChromeDevTools/chrome-devtools-mcp/pull/2374
Native-context summaries: https://github.com/ChromeDevTools/chrome-devtools-mcp/pull/2375
Native-context filtering: https://github.com/ChromeDevTools/chrome-devtools-mcp/pull/2377
Native-tool skill update: https://github.com/ChromeDevTools/chrome-devtools-mcp/pull/2436
Failed-load worker cleanup: https://github.com/ChromeDevTools/chrome-devtools-mcp/pull/2449
Demand wording only — community memory-profiling comparison: https://www.reddit.com/r/ClaudeAI/comments/1p4nmm6/cli_vs_mcp_benchmark_results_chrome_devtools/

GitHub Copilot for JetBrains: use Ollama without confusing local inference with local memory

Ahab — Wed, 12 Aug 2026 01:20:50 +0000

GitHub Copilot for JetBrains: use Ollama without confusing local inference with local memory

Quick answer

GitHub Copilot for JetBrains now supports Ollama as a local BYOK provider and can retain Copilot Memory across agent chat sessions. Treat them as two separate controls.

Ollama can keep model inference on your machine when the selected endpoint is loopback and the selected model is local. Copilot Memory stores repository facts and user preferences under GitHub's memory controls. Enabling a local model does not prove that memory, account, session sync, telemetry, MCP calls, or cloud-agent work also stays local.

Roll out in two lanes: first prove the local inference path with Memory disabled, then decide whether to enable Memory and audit what it stores.

Who this is for

This guide is for IntelliJ IDEA, Android Studio, PyCharm, WebStorm, and other JetBrains users who want Copilot's agent workflow with a locally served model, or who need to review the privacy boundary before enabling persistent context.

It is also for organization administrators. GitHub says local BYOK in IDEs can be disabled by organization or enterprise policy, while Copilot Memory has its own policy and user toggle. The existing Copilot managed-settings guide explains why client access and runtime controls must be tested separately.

What changed on August 11

GitHub's release adds four notable JetBrains capabilities: enterprise-managed settings, cross-session Copilot Memory, Ollama as a BYOK provider, and expanded Codex workflows. The release says Ollama provider configuration and model selection are available throughout the JetBrains experience.

GitHub's BYOK documentation distinguishes local BYOK from enterprise BYOK. Local keys and provider configuration are handled client-side, and a local model can remove the dependency on GitHub's Copilot model API. Enterprise BYOK is different: it is handled server-side and still requires a Copilot license and internet access.

Memory is a separate public-preview system. It can store repository-level facts such as build commands and architecture decisions, plus user-level preferences. Repository facts are citation-backed and revalidated against the current branch. Unused entries expire after 28 days, and users or administrators can review and delete them.

Boundary matrix

Surface	What the official material confirms	What you must verify
Ollama model inference	JetBrains supports Ollama as a local BYOK provider	Endpoint is `127.0.0.1`, local model is selected, and requests reach the local process
Copilot Memory	Repository facts and user preferences persist under GitHub controls	Policy, billing owner, stored entries, citations, deletion, and whether you need it
JetBrains plugin	Provider/model selection and agent chat are integrated	Exact plugin and IDE builds, selected provider after restart, and fallback behavior
Other agent paths	Release also covers MCP, Codex, terminals, and cloud agents	Network destinations, permissions, session sync, and every non-model tool path

The safe claim is narrow: the model request was served by local Ollama. Do not upgrade that claim to “Copilot is fully offline” without separate network and feature evidence.

A six-gate rollout

1. Record the exact client and policy state

Update to the latest compatible GitHub Copilot plugin, then record the plugin version, JetBrains product/build, account, active billing entity, organization policies, and current Memory state. Do not rely on “latest” as durable evidence.

2. Keep Ollama on loopback

Ollama binds to 127.0.0.1:11434 by default. Keep that default for a single-machine IDE setup. Do not set OLLAMA_HOST=0.0.0.0:11434, add a tunnel, or expose the port merely to make discovery easier.

If you want an explicitly local-only Ollama service, disable its cloud features:

{
  "disable_ollama_cloud": true
}

Then restart Ollama and confirm its logs report that cloud support is disabled. This controls Ollama; it does not disable GitHub-side Copilot features.

3. Prove the provider, not just the answer

In JetBrains, configure Ollama, choose one already-downloaded local model, start a fresh chat, and submit a harmless prompt with a unique marker. Capture:

the selected provider and model in the UI;
the local Ollama request log or process activity for that marker;
the absence of an automatic fallback to a GitHub-hosted model;
the result after restarting both the IDE and Ollama.

If the UI says Ollama but no local request appears, stop. A plausible answer is not routing evidence.

4. Test the failure path

Stop Ollama and repeat the harmless prompt. The acceptable result is a clear local-provider failure or an explicit, user-approved provider switch. Silent fallback fails the gate. Restart Ollama and confirm the same model works again.

For larger open models, check hardware before downloading. The local-model hardware checklist shows why “open” and “laptop-ready” are different claims.

5. Audit Memory separately

Keep Memory disabled during the routing test. If you later enable it, use a disposable repository with a harmless convention such as npm run verify:fixture. Interact as a user with write access, then review repository facts under the repository's Copilot Memory settings and user preferences in personal Copilot settings.

Record any fact, its citation, owner, and deletion result. Do not seed passwords, customer data, private URLs, or production architecture secrets. Memory creation is not guaranteed for every sentence; if no entry appears, record “not observed” instead of claiming it was stored.

6. Gate production use

Approve the rollout only if local routing, stopped-server behavior, restart persistence, policy enforcement, memory inspection, and deletion all match the intended boundary. Keep a one-step rollback: switch provider, disable Memory, or disable the local-BYOK policy.

Decision tree

Need only local model inference? Keep Memory off and validate Ollama routing first.
Need persistent repository context? Enable Memory only after ownership, review, retention, and deletion are acceptable.
Need a fully offline or air-gapped workflow? Disable unrelated cloud features and prove network behavior; the JetBrains release alone is not evidence.
Organization policy hides Ollama? Ask the administrator to review local BYOK policy; do not work around it with an exposed endpoint.
Local model lacks tool quality or context? Route only bounded chat tasks to it and keep agentic writes on a separately evaluated model.

Common mistakes

Calling the whole Copilot workflow local because the LLM runs in Ollama.
Enabling Memory and Ollama together, then being unable to attribute behavior.
Exposing port 11434 to the LAN or internet without a real access-control design.
Confusing local BYOK with enterprise BYOK, which uses a server-side path.
Trusting the model name shown in prose instead of observing the local request.
Testing persistence with secrets or sensitive repository facts.
Assuming a stored fact is permanent; unused Memory entries expire and facts are revalidated.

For other local-control boundaries, see the Qwen trusted-LAN checklist. For tools that can act on external data, use the connector security checklist.

Copyable acceptance record

date / owner:
jetbrains_product_build:
copilot_plugin_version:
account / billing_entity:
local_byok_policy: enabled | disabled
memory_policy / user_toggle:
ollama_bind: 127.0.0.1:11434 | other
ollama_cloud_disabled: yes | no
selected_provider / model:
local_request_observed: pass | fail
stopped_server_fails_closed: pass | fail
restart_preserves_selection: pass | fail
memory_fact_observed / citation:
memory_delete_verified: pass | fail | not tested
non_model_network_paths_reviewed:
rollback_action / owner / evidence:

FAQ

Does Ollama make GitHub Copilot for JetBrains fully offline?

It can localize the model-provider path. Other Copilot capabilities have separate account, memory, session, tool, and network behavior. Verify those independently before making an offline claim.

Is Copilot Memory stored inside Ollama?

No official source says that. GitHub documents Memory as repository facts and user preferences managed through GitHub Copilot settings. Treat it as a separate service and control plane.

Should I expose Ollama so JetBrains can find it?

Not for a same-machine setup. Ollama's documented default is loopback. Keep it there unless you have a deliberate authenticated network design.

Sources

GitHub Copilot for JetBrains release: https://github.blog/changelog/2026-08-11-copilot-memory-and-ollama-in-github-copilot-for-jetbrains
GitHub Copilot BYOK concepts: https://docs.github.com/en/copilot/concepts/models/bring-your-own-key
About GitHub Copilot Memory: https://docs.github.com/en/copilot/concepts/agents/copilot-memory
Manage personal Copilot Memory: https://docs.github.com/en/copilot/how-tos/use-copilot-agents/copilot-memory/manage-for-yourself
Manage organization and enterprise Memory: https://docs.github.com/en/copilot/how-tos/use-copilot-agents/copilot-memory/manage-as-administrator
Ollama network and local-only guidance: https://docs.ollama.com/faq
JetBrains local-LLM demand signal: https://github.com/microsoft/copilot-intellij-feedback/issues/593

Claude Code 2.1.227: Restore Bash in Claude Code Action Without Dropping the Sandbox

Ahab — Tue, 11 Aug 2026 10:19:45 +0000

Claude Code 2.1.227: restore Bash in Claude Code Action without dropping the sandbox

Quick answer

Claude Code 2.1.227 fixes a regression where every Bash command could fail under claude-code-action on GitHub-hosted runners when allowed_non_write_users was configured. Claude Code Action 1.0.190 pins that fixed CLI generation.

Upgrade, prove the job installed Claude Code 2.1.227+, and check a disposable Bash marker in a separate step. Do not use CLAUDE_CODE_SUBPROCESS_ENV_SCRUB: "0" as the production fix: it disables protections for untrusted-input workflows.

Who this is for

This guide is for maintainers whose Claude Code Action workflow accepts issue or pull-request input from users without repository write access. The recognizable failure is a Bash tool error such as:

bwrap: Can't create file at /home/.mcp.json: Permission denied

Read, Write, or Edit may still appear to work while shell-dependent tests, commits, or pushes never happen. That makes the workflow dangerous to judge from Claude's final narration alone.

Unlike the 2.1.223 permission-regression checklist or 2.1.224 self-hosted environment guide, this task restores the GitHub-hosted action's non-write-user sandbox.

What changed in 2.1.227

Anthropic's 2.1.227 release explicitly says it fixed every Bash command failing under claude-code-action with allowed_non_write_users on GitHub-hosted runners. The corresponding Claude Code Action 1.0.190 source pins Claude Code 2.1.227 and Agent SDK 0.3.227.

The security boundary remains mandatory. allowed_non_write_users bypasses the normal write-access check and requires a github_token input. Official guidance calls it risky, removes secrets from subprocess environments on a best-effort basis, adds PID-namespace isolation on supported Linux runners, and requires the job-scoped GITHUB_TOKEN, minimal permissions, and narrow tools.

Release and protection matrix

Lane	Effective version	Scrub/isolation	Decision
Known bad symptom	Claude Code 2.1.216–2.1.220 in the public report	Enabled	Do not accept narrative success; upgrade
Emergency diagnosis only	Any affected build with scrub set to `0`	Disabled	Confirms coupling, but is not a production fix
Recovery candidate	Action 1.0.190 with CLI 2.1.227	Enabled	Run all canaries before restoring writes
Production	Fixed version pinned by tag or commit	Enabled, minimal permissions and narrow tools	Ramp from read-only or labeling work

The first row is public reproduction evidence, not an official support range. The shipped fact is the 2.1.227 fix; use the job's install log as truth.

A six-canary recovery

1. Pin the recovery candidate

Use anthropics/claude-code-action@v1.0.190, or pin the reviewed commit. With mutable @v1, record the resolved action commit and CLI on every run.

2. Keep the protection path on

Remove any emergency CLAUDE_CODE_SUBPROCESS_ENV_SCRUB: "0" override. Use only ${{ secrets.GITHUB_TOKEN }} for github_token, never a PAT. Start with the smallest event and permissions: set. For an issue-labeling flow, do not grant contents: write or pull-request writes just because a future workflow might need them.

3. Run a payload-free Bash marker

In a disposable repository or branch, ask Claude to execute exactly one harmless command and read it back:

- uses: anthropics/claude-code-action@v1.0.190
  with:
    github_token: ${{ secrets.GITHUB_TOKEN }}
    allowed_non_write_users: "test-contributor"
    prompt: |
      Run `printf 'CLAUDE_BASH_OK\n' &gt; claude-bash-smoke.txt`, then read the file.
      Do not modify any other file.
    claude_args: |
      --allowedTools "Bash"

- name: Verify Bash executed outside the model narrative
  shell: bash
  run: test "$(tr -d '\r\n' &lt; claude-bash-smoke.txt)" = "CLAUDE_BASH_OK"

Broad Bash permission is acceptable only in this empty, disposable canary. Replace it with command-scoped tools in the real workflow.

4. Prove secrets stay out of child processes

Use fake sentinel credentials, never production secrets. Ask Bash to report only whether known credential variables are absent, and fail if a sentinel value appears in logs, files, comments, artifacts, or the final answer. Keep the parent action's required authentication separate from the child-process assertion.

5. Prove actor and capability denial

Test one named allowed user, one unlisted non-write user, and one bot. Confirm only the named user reaches Claude, and that the job cannot write outside its declared purpose. Avoid allowed_non_write_users: "*"; an allowlist does not make untrusted prompts safe.

6. Gate rollout on external evidence

Require the Bash marker, expected versions, no scrub opt-out, no leaked sentinel, correct actor decision, and expected GitHub result. A green conclusion or confident assistant message is insufficient. If the older CLI is broken, roll back workflow capability instead of the CLI.

Decision tree

If allowed_non_write_users is not configured, investigate a different Bash failure.
If the log shows a CLI older than 2.1.227, update the action or fix a stale pin.
If 2.1.227+ is installed but the marker fails, preserve logs and stop; do not disable scrubbing in production.
If the marker passes but the actor or secret canary fails, reduce permissions and tools before any rollout.
Only restore write-capable automation after all six gates pass on the same action commit and runner image.

Common mistakes

Assuming @v1 always means the same bits; record the resolved commit and CLI.
Treating an open issue's inferred root cause as the product contract. The official release confirms the fix, not every internal mechanism.
Keeping the scrub opt-out because it made Bash work once.
Using a PAT with untrusted prompts or granting broad contents: write permissions.
Asking Claude whether Bash worked instead of asserting an external marker.
Retesting with a real secret, repository, or release credential.

For additional egress controls, pair this recovery with the strict network allowlist checklist. For actor-to-write authority, use the GitHub issue agent approval-confidence checklist.

Copyable acceptance record

action_ref / resolved_commit:
installed_claude_code_version:
runner_image:
allowed_non_write_users: named list | wildcard
subprocess_env_scrub_override: absent | present
workflow_permissions:
allowed_tools:
bash_marker_external_assertion: pass | fail
fake_secret_absent_from_child_outputs: pass | fail
unlisted_actor_denied: pass | fail
expected_write_scope_only: pass | fail
rollback_ref:
owner / evidence_url / decision:

FAQ

Can I fix the failure by setting `CLAUDE_CODE_SUBPROCESS_ENV_SCRUB` to `0`?

It can diagnose the old coupling, but it removes protections intended for untrusted-input workflows. Upgrade and verify 2.1.227+ instead.

Is `allowed_non_write_users: "*"` safe after the fix?

No. The fix restores Bash execution; it does not make arbitrary contributor prompts trusted. Prefer named users, minimal permissions, narrow tools, and deterministic output validation.

Why check a marker in another step?

The reported regression could leave non-shell tools functioning and still produce a successful-looking answer. The marker proves the command actually ran independently of the model's claim.

Sources

Claude Code 2.1.227 release: https://github.com/anthropics/claude-code/releases/tag/v2.1.227
Claude Code Action 1.0.190 release: https://github.com/anthropics/claude-code-action/releases/tag/v1.0.190
Official action pin to Claude Code 2.1.227: https://github.com/anthropics/claude-code-action/commit/5ef2e550a465a721f4f45e4a7d3c340c873e1dcc
Claude Code Action security guidance: https://github.com/anthropics/claude-code-action/blob/main/docs/security.md
Public symptom and reproduction report: https://github.com/anthropics/claude-code-action/issues/1547

Qwen Code 0.21.9 Local Control: Pair a Phone Without Exposing Your Agent

Ahab — Tue, 11 Aug 2026 01:18:10 +0000

Qwen Code 0.21.9 Local Control: pair a phone without exposing your agent

Quick answer

Qwen Code 0.21.9 adds Local Control to the CLI and Desktop app. Run qwen serve --local-control, or choose Control → Local Control… in Desktop, and Qwen shows a QR code that opens the active local session from a phone on the same network. Files, credentials, tools, and execution stay on the host computer.

The important boundary is easy to miss: Local Control uses a fresh 256-bit bearer token and strict browser origins, but its LAN connection is unencrypted HTTP. Use it only on a trusted private network. Never expose it through router port forwarding, a public address, or an anonymous tunnel. Treat the QR code as a temporary secret, supervise permissions as if you were at the host, and prove that turning the mode off revokes both the listener and token.

Who this is for

This guide is for developers who start a long Qwen Code task and want to watch progress, answer a permission prompt, or continue from a phone without moving the workspace to a cloud runner.

Local Control does not replace workspace trust or tool permissions. Keep the project boundary from the Qwen Code workspace-trust checklist and the action boundary from the agent permission regression checklist.

What shipped in 0.21.9

The stable August 10 release turns a manual LAN recipe into an explicit mode. The CLI binds its Web Shell to the IPv4 LAN, generates a token with 32 random bytes, prints QR codes for usable LAN addresses, and keeps the host awake. Protected HTTP and WebSocket routes retain bearer authentication and exact browser origins.

Desktop's normal daemon remains authenticated and loopback-only. Enabling Local Control starts a temporary LAN gateway, substitutes a pairing credential, and opens the session active when pairing began. Turning it off closes connections and invalidates the token.

The transport remains intentionally limited to same-network access. The official implementation says internet control needs an account-authenticated outbound relay and must not be approximated with port forwarding or an unauthenticated tunnel.

The boundary matrix

Boundary	CLI	Desktop	Acceptance rule
Enablement	Explicit `--local-control`	Explicit menu toggle	No LAN listener before opt-in
Host runtime	Web Shell binds to IPv4 LAN	Private daemon stays on loopback; temporary gateway faces LAN	Existing session and daemon identity remain stable
Credential	Fresh 256-bit token per run	Separate short-lived pairing token	Old token fails after disable/re-enable
Browser access	Exact advertised origins plus loopback self-origin	Gateway validates public Host and Origin	Wrong origin or token is rejected
Transport	HTTP on the trusted LAN	HTTP on the trusted LAN	No public Wi-Fi, forwarding, or anonymous tunnel
Stop action	`Ctrl+C`	Turn off Local Control or close its window	Listener, connections, token, and sleep inhibition end

The URL fragment keeps the token out of the initial request, access log, and referrer; it does not add TLS. A QR screenshot or full link can still grant control, so do not share it.

A six-canary rollout

1. Establish the host boundary

Upgrade to stable 0.21.9 or later. Confirm the workspace, session, model, MCP servers, hooks, and approval policy. Phone access carries the host session's authority; it does not create a safer permission profile.

2. Establish the network boundary

Use a private network you control, without port forwarding or tunnel software. Desktop fails closed unless it verifies a private or link-local physical IPv4 address. Support here is IPv4-focused; do not infer an IPv6 or internet guarantee.

3. Pair through the supported entry point

For CLI:

qwen serve --local-control

Do not combine it with custom --hostname, --token, --allow-origin, --no-web, or port 0; the command rejects these conflicts. In Desktop, open Control → Local Control… and keep the network warning visible.

4. Prove session continuity without a write

Scan from the same private network. Confirm Desktop opens the session active at enable time. Start with a read-only prompt for the session title and repository root. After switching Desktop sessions, toggle Local Control to generate a new link.

5. Prove authentication and origin denial

Try a credential-free browser profile or altered token; protected capabilities must not load. Keep the test payload-free and real credentials out of URLs, screenshots, history, and logs.

6. Prove revocation

Stop CLI with Ctrl+C, or turn off Desktop Local Control. The phone page and WebSocket should lose access; the old link must fail. Re-enable and confirm a new credential, then verify normal host sleep returns.

Common mistakes

Calling the mode “encrypted” because the token is strong. Authentication strength and transport encryption are different controls.
Using hotel, airport, coworking guest, or other untrusted Wi-Fi for an HTTP control session.
Publishing the listener through router forwarding, Cloudflare Tunnel, ngrok, or a similar public relay. That is outside the supported threat model.
Leaving Local Control on after the phone task ends, or assuming closing the phone tab revokes host access.
Sharing the QR screenshot in a bug report. Redact the entire code and URL.
Treating phone supervision as permission bypass. Keep destructive actions and credential access behind the same human approval gates used at the host.

For durable internet control, use authenticated outbound relay, reconnectable sessions, device identity, and transport encryption. A LAN gateway is not a substitute for the self-hosted agent trust boundary.

Copyable acceptance record

qwen_version:
host_os / private_ipv4:
workspace / session_id:
entry_point: cli | desktop
lan_listener_absent_before_enable: pass | fail
phone_opens_expected_session: pass | fail
wrong_token_denied: pass | fail
unexpected_origin_denied: pass | fail
old_link_revoked_after_disable: pass | fail
new_token_after_reenable: pass | fail
sleep_inhibitor_released: pass | fail
public_forwarding_or_tunnel: none
owner / expiry_time / decision:

FAQ

Does Local Control upload my repository to Qwen?

It exposes the host's Web Shell on the LAN; files, credentials, tools, and execution remain there. The model provider's data path is unchanged.

Is the pairing link safe to use over the internet?

No. The official scope is a trusted same-network connection over unencrypted HTTP. Internet remote control is explicitly outside this mode.

Does Local Control keep the computer awake?

Yes, while the mode is active. Stopping Local Control releases the sleep inhibitor; include that in the revocation test.

Sources

Qwen Code 0.21.9 release: https://github.com/QwenLM/qwen-code/releases/tag/v0.21.9
Qwen Code Local Control design: https://github.com/QwenLM/qwen-code/blob/main/docs/design/local-control-cli.md
Qwen Code Local Control CLI/Desktop implementation: https://github.com/QwenLM/qwen-code/pull/8727
Qwen Code active-session and private-address hardening: https://github.com/QwenLM/qwen-code/pull/8806

GPT-5.6 Fast mode long context: price the 272K threshold before rollout

Ahab — Mon, 10 Aug 2026 10:22:42 +0000

GPT-5.6 Fast mode long context: price the 272K threshold before rollout

Quick answer

OpenAI's August 5 API update lets GPT-5.6 Sol, Terra, and Luna run prompts above 272K tokens in Fast mode. Fast mode can deliver up to 2.5 times faster responses, but it charges a per-token premium. A long-context request already moves the whole request onto higher long-context rates, so enabling Fast mode can compound the bill.

Use Fast mode only when saved wall-clock time changes a user or business outcome. Benchmark the same fixture on Standard and Fast, verify the response's actual service_tier, calculate cost per accepted result, and roll out with a feature flag. Do not enable it globally because a context window is large.

Who this is for

This guide is for developers sending large repositories, document sets, research packets, or agent histories to the OpenAI API. It assumes you already chose Sol, Terra, or Luna. If model choice is still open, start with the GPT-5.6 Sol vs Terra vs Luna guide.

The task here is narrower: decide whether long-context Fast mode earns its latency premium without hiding a tier downgrade, a quality regression, or an unexpected spend jump.

What changed and what did not

Fast mode was previously called Priority processing. Requests may send either service_tier: "fast" or service_tier: "priority". For GPT-5.6 and earlier models, a request actually served on Fast returns service_tier: "priority"; a ramp-rate downgrade returns default.

The August 5 change adds long-context support to Fast mode for all three GPT-5.6 models. It does not mean every response is 2.5 times faster, nor does it make long context cheaper. OpenAI's model pages state that prompts above 272K input tokens price the entire request at twice the normal input rate and 1.5 times the normal output rate. Fast mode then applies its own premium.

Current prices per 1M tokens show the combined boundary clearly:

Model	Standard long input / output	Fast long input / output	No-cache example: 300K in + 10K out
GPT-5.6 Sol	$10 / $45	$20 / $90	$3.45 Standard / $6.90 Fast
GPT-5.6 Terra	$4 / $18	$8 / $36	$1.38 Standard / $2.76 Fast
GPT-5.6 Luna	$0.40 / $1.80	$0.80 / $3.60	$0.138 Standard / $0.276 Fast

Cached input and explicit cache-write prices also have separate Standard/Fast and short/long columns. Use the live pricing table for production math; do not copy one headline token rate into every route.

The rollout decision

Use this decision tree before writing code:

Can the prompt stay at or below 272K through retrieval, compaction, or cleaner inputs?
  Yes -> benchmark short-context Standard first.
  No  -> benchmark long-context Standard on a fixed fixture.

Does p95 latency block a high-value, user-facing outcome?
  No  -> keep Standard; consider Batch or Flex for offline work.
  Yes -> run the same fixture in Fast and measure the actual tier.

Does Fast improve accepted-result latency enough to cover its incremental cost?
  No  -> keep Standard.
  Yes -> canary by request class, ramp gradually, retain one-switch rollback.

For the Terra example above, Fast adds $1.38 per request. If it saves 10 seconds, the premium is $0.138 per second saved. Compare that number with abandonment, operator wait time, or revenue at risk—not with an abstract wish for speed.

A measurable canary

Keep the tier request explicit and record the tier actually returned:

const mode = process.env.FAST_CANARY === "1" ? "fast" : "default";

const response = await client.responses.create({
  model: "gpt-5.6-terra",
  input: fixedEvaluationFixture,
  service_tier: mode
});

record({
  requestedTier: mode,
  actualTier: response.service_tier,
  latencyMs,
  inputTokens: response.usage?.input_tokens,
  outputTokens: response.usage?.output_tokens,
  accepted: passedTaskSpecificVerifier(response.output_text)
});

Run at least 20 matched Standard/Fast pairs for each request class. Keep the model, snapshot, reasoning effort, prompt, tools, cache state, and verifier constant. Compare p50 and p95 accepted-result latency, not one attractive screenshot.

Six production gates

Context gate: test fixtures just below and above 272K so the pricing transition is visible.
Quality gate: require the same task-specific verifier; faster incomplete answers do not pass.
Tier gate: count priority, default, errors, and retries from the returned response.
Economics gate: calculate total cost per accepted result, including retries and cache writes.
Traffic gate: shift one request class behind a feature flag and ramp over hours.
Rollback gate: one configuration change restores Standard without changing model or prompt.

OpenAI says Standard and Fast share the same model rate limit. At at least 1 million tokens per minute, increasing traffic by more than 50% within 15 minutes may trigger a ramp-rate downgrade. Downgraded requests run at standard speed, return service_tier: "default", and receive standard pricing. Record this instead of treating every requested Fast call as delivered Fast.

Common mistakes

Sending batch, ETL, or background work to Fast; OpenAI explicitly recommends avoiding large ETL jobs in this tier.
Treating service_tier: "fast" in the request as proof of the tier actually used.
Comparing raw latency while ignoring acceptance rate, retries, output length, and cache state.
Crossing 272K with irrelevant history instead of first testing retrieval or compaction.
Switching an entire project to Fast before a request-level canary.
Hard-coding today's prices without a budget alert or hard spend-limit runbook.

Copyable acceptance record

request_class:
model_and_snapshot:
fixture_hash:
input_tokens / output_tokens:
standard_p50 / p95 / accepted_rate / cost_per_accept:
fast_p50 / p95 / accepted_rate / cost_per_accept:
returned_priority_rate / returned_default_rate:
maximum_incremental_cost_per_saved_second:
ramp_schedule:
rollback_flag_and_owner:
decision: keep_standard | canary_fast | roll_back

FAQ

Does a prompt above 272K automatically use Fast mode?

No. Long context and processing tier are separate choices. Use service_tier or the project setting to request Fast.

Are `fast` and `priority` the same API setting?

They request the same supported processing tier. For GPT-5.6 and earlier models, the response reports priority when Fast was used.

Should an offline long-document pipeline use Fast?

Usually not. Start with Standard, Batch, or Flex. Fast is designed for valuable user-facing latency, and the official guide advises against large ETL workloads.

What should I monitor after rollout?

Track requested versus returned tier, p50/p95 latency, token counts, cache reads and writes, acceptance rate, retry rate, and cost per accepted result. The Cloudflare AI Gateway spend workflow is a useful adjacent pattern for identity-aware cost attribution.

Sources

OpenAI API changelog: https://developers.openai.com/api/docs/changelog
OpenAI API Fast mode guide: https://developers.openai.com/api/docs/guides/fast-mode
OpenAI API pricing: https://developers.openai.com/api/docs/pricing
OpenAI GPT-5.6 Sol model page: https://developers.openai.com/api/docs/models/gpt-5.6-sol
OpenAI GPT-5.6 Terra model page: https://developers.openai.com/api/docs/models/gpt-5.6-terra
OpenAI GPT-5.6 Luna model page: https://developers.openai.com/api/docs/models/gpt-5.6-luna

Codex CLI 0.147 --approve-for-me: verify Auto-review before unattended runs

Ahab — Mon, 10 Aug 2026 01:19:47 +0000

Codex CLI 0.147 --approve-for-me: verify Auto-review before unattended runs

Quick answer

Codex CLI 0.147.0, released on August 7, 2026, adds --approve-for-me to interactive and exec commands. The flag routes eligible approval requests to Codex Auto-review, a separate reviewer agent. It does not turn on Full access: the implementation selects approval_policy="on-request" with the workspace-write sandbox, and later subcommand permission overrides still take precedence.

That distinction is the rollout gate. Auto-review changes who reviews a boundary-crossing request; it does not expand writable roots, enable network access, or make destructive actions safe. Before using the flag for unattended work, run six harmless canaries that prove the sandbox, approval route, denials, audit trail, resume behavior, and rollback.

Who this is for

This guide is for developers running long Codex CLI tasks, scheduled local maintenance, or codex exec workflows that should continue through ordinary approval decisions without granting unrestricted machine access.

It is not a recipe for bypassing approvals. If a workflow genuinely requires broad host access, production credentials, irreversible deletion, deployment, payment, or external messaging, keep that authority explicit and human-controlled. Start with the untrusted-repository sandbox checklist and narrow the task until most work fits inside workspace-write.

What changed, and what did not

The 0.147.0 changelog describes --approve-for-me as automatically reviewed approvals. The merged implementation propagates it through root, exec, resume, and fork argument handling. The official Auto-review documentation defines the stronger boundary: the main agent stays inside the same sandbox, while eligible escalation requests go to a reviewer agent.

Control	With `--approve-for-me`	What to verify
Approval policy	Interactive `on-request`	Boundary requests are reviewed rather than silently allowed
Sandbox	`workspace-write` preset	Writes remain limited to intended roots
Network	Not granted by Auto-review	A blocked destination still requires a review decision
Reviewer	`approvals_reviewer="auto_review"`	Eligible prompts go to the reviewer, not directly to a person
Denial	Main agent must choose a materially safer path or stop	No repeated workaround or policy-circumvention loop
Overrides	Later subcommand permission flags win	The effective mode matches the invocation you audited

Auto-review can evaluate shell escalation, blocked network requests, out-of-root edits, approval-gated MCP or app calls, and access to a new Computer Use domain. Routine actions already allowed by the sandbox do not invoke the reviewer. Computer Use app approvals remain a separate user-facing case.

Six-canary rollout

Use a disposable repository with no real credentials. Record the Codex version, exact command, effective permissions, expected result, actual result, and retained evidence for every canary.

1. Prove the positive path inside the workspace

Start an interactive canary with:

codex --approve-for-me

Ask it to create and remove one sentinel file inside the disposable repository, then run a local test that needs no network. The work should remain inside workspace-write without an escalation. This proves ordinary workspace work does not create approval noise.

For non-interactive use, test the flag on codex exec separately. Do not assume the interactive result proves your scheduled entrypoint.

2. Prove the filesystem boundary

Ask the canary to write a harmless sentinel just outside the configured writable root. The action must not silently succeed. Verify that Auto-review receives an exact boundary-crossing request and that the final filesystem state matches the decision.

Do not broaden the root merely to make the test pass. If a neighboring directory is genuinely required, add only that directory after reviewing ownership and contents.

3. Prove network remains independently controlled

With command network access disabled, request a harmless fetch from a public documentation host. The network request should encounter the configured boundary and follow the review path; --approve-for-me alone must not make the destination reachable.

If the real workflow needs network access, use a narrow allowlist. A global wildcard turns an approval convenience into a much larger data-exfiltration surface.

4. Prove secret and destructive denials with fake data

Create a file containing a disposable value such as TEST_ONLY_TOKEN_DO_NOT_USE. Ask Codex to send it to an untrusted example destination, and separately request deletion outside the fixture. Expected result: denial, a visible rationale, and no external transmission or unintended deletion.

Never place a real token in an adversarial canary. The official policy is designed to block credential probing, secret disclosure, broad security weakening, and high-impact destructive actions, but Auto-review is not a deterministic security guarantee.

5. Prove denial recovery and resume/fork parity

After a denial, the agent should either choose a materially safer route or ask you—not retry the same outcome indirectly. Then resume the task and fork it once, confirming that the effective approval and sandbox modes remain the ones you intended.

Codex has a denial circuit breaker, but your operating rule should be stricter: one unexplained repeated escalation is enough to pause the rollout and inspect the request history.

6. Prove audit and rollback

Inspect the retained task transcript and confirm each reviewed action has a decision, rationale where available, requested scope, and outcome. Then rerun the same fixture without --approve-for-me; eligible requests should return to human review. Finally, prove that your scheduler or wrapper can remove the flag without changing unrelated configuration.

Decision tree

Can the task finish inside workspace-write with no network?
├─ Yes → Use the normal sandbox; Auto-review should be rare.
└─ No
   ├─ Is the extra file root or destination narrow and repeatable?
   │  ├─ Yes → Add the narrow boundary, then rerun all six canaries.
   │  └─ No → Keep human approval.
   └─ Does the action send data, use production credentials, or cause irreversible effects?
      ├─ Yes → Keep explicit human authority.
      └─ No → Canary --approve-for-me, monitor denials, and retain rollback.

Copyable acceptance record

codex_auto_review_rollout:
  codex_version: "0.147.0"
  entrypoint: "interactive | exec | resume | fork"
  sandbox: "workspace-write"
  approval_policy: "on-request"
  reviewer: "auto_review"
  writable_roots: ["disposable repository only"]
  network: "off | narrow allowlist"
  canaries: ["workspace", "outside-root", "network", "fake-secret", "denial-recovery", "rollback"]
  production_authority: "human for secrets, destructive actions, deploys, payments, and messages"
  rollback: "remove --approve-for-me and restore human reviewer"

This is an operating record, not an OpenAI configuration schema.

Common mistakes

Treating Auto-review as Full access. It is a reviewer swap at the sandbox boundary, not a permission grant.

Testing only the happy path. A workspace edit proves almost nothing about out-of-root writes, network, secrets, or destructive actions.

Using real credentials in a denial test. A failed safety control would leak the thing you were trying to protect. Use disposable sentinels only.

Ignoring later CLI overrides. Root and subcommand flags have precedence. Capture the exact production invocation instead of reviewing a simplified command.

Customizing policy before measuring. First run the default policy and inspect real review traffic. Broad approval instructions can erase the boundary you intended to keep.

FAQ

Is `--approve-for-me` equivalent to `--dangerously-bypass-approvals-and-sandbox`?

No. The bypass flag removes both protections and is intended only for an externally hardened environment. --approve-for-me keeps interactive approval plus workspace-write and delegates eligible reviews.

Can I set the same behavior in `config.toml`?

The configuration reference documents approvals_reviewer = "auto_review" for eligible on-request or granular approvals. Keep the sandbox and approval policy explicit; changing the reviewer alone does not grant new access.

Does an Auto-review approval prove the action is safe?

No. It is one risk-control decision based on available context. Keep OS sandboxing, least privilege, monitoring, bounded tasks, and human authority for high-impact effects.

Sources

Claude Managed Agents Session Budget Checklist

Ahab — Sun, 09 Aug 2026 10:21:28 +0000

Claude Managed Agents session budgets: prove the hard stop before unattended runs

Quick answer

On August 7, 2026, Anthropic added hard per-session budgets to Claude Managed Agents. A budget is a US-dollar ceiling, written as whole cents, that the platform enforces against the session's public-list-price cost. When the cap is reached, the session pauses with the session-level stop reason budget_reached; it does not terminate. Raising or removing the budget resumes the paused work automatically.

This is an API-level Claude Managed Agents feature. It is not a Claude Code subscription meter, and it is different from the Messages API's advisory, token-denominated task budgets.

Do not treat the number as an exact final invoice or a mid-request kill switch. Enforcement happens between model requests. An in-flight request finishes, so one request per active thread can take the recorded list cost past the cap. Use the rollout below to prove event ordering, overshoot, blocked new work, and resume authority before trusting the cap on unattended agents.

Who this is for

This guide is for developers running Claude Managed Agents through the REST API or Anthropic SDKs, especially scheduled deployments, long research sessions, tool-heavy agents, and multiagent coordinators. It is useful when a job must stop starting new model work before one failed loop consumes an open-ended budget.

The feature is a financial guardrail, not a task-quality guarantee. Keep outcome checks, permission policies, tool timeouts, and human approval for irreversible actions.

What the budget actually controls

The platform continuously computes a session's list cost. The official documentation includes model tokens at each model's public list price, web search at $10 per 1,000 searches, and active session runtime at $0.08 per hour. Negotiated discounts do not change when the cap fires, so the budget is not necessarily the amount your organization will be billed.

Boundary	Official behavior	Operational consequence
Unit	Whole US cents as a string; `"2500"` means $25	Reject decimal strings and floating-point conversion
Attachment	Set only when the session is created	An unbudgeted existing session cannot receive a cap later
Enforcement	Checked before each new model request	A request already running can finish past the cap
Stop state	Session becomes idle with `budget_reached`	Preserve state; do not classify it as completion or failure
Multiagent	One shared cap across all threads and advisors	Parallel in-flight requests increase the overshoot margin
Deployment	Budget is copied to each future session	It is a per-run ceiling, not one cumulative deployment budget
Resume	Raise the cap or remove it	An accepted update resumes work without another user message

Removing a session budget is one-way: the same session cannot receive a new budget later. Changing a deployment budget is different; it affects sessions started afterward, and a cleared deployment budget can be set again.

A budget-sizing rule that survives concurrency

Start from accepted work, not a guess about average tokens. Run representative tasks without a cap, record the p50 and p95 session usage.list_cost, then choose a canary cap that is high enough for one normal task but low enough to stop a loop.

Use this planning record:

Task class:
Observed p50 list cost:
Observed p95 list cost:
Maximum concurrent threads:
Largest plausible single request per thread:
Web-search allowance:
Runtime allowance:
Canary cap:
Expected overshoot margin:
Who may raise the cap:
Maximum approved cap:

The important margin is not a fixed percentage. It is the sum of the largest plausible in-flight request on each active thread. A single-threaded session has one-request exposure; a coordinator with four active threads can have four requests complete after the cap decision.

Six-canary rollout

1. Create a disposable budgeted session

Use a non-production agent and harmless task. The request must include the Managed Agents beta header and a budget at creation:

{
  "agent": "agent_test",
  "environment_id": "env_test",
  "budget": {
    "type": "limit",
    "max_list_cost": { "amount": "50", "currency": "USD" }
  }
}

Keep API keys in environment variables; never copy them into the request body or an audit record. Confirm the returned session echoes the intended budget.

2. Prove the stop signal and event order

Run a bounded workload designed to cross the small canary cap. The session must become idle with session-level stop_reason: budget_reached. Immediately before the final session.status_idle event, expect a cumulative session.usage snapshot.

A thread can report end_turn even when the session reports budget_reached. Use the session-level reason as the authority for the budget decision.

3. Measure overshoot instead of calling it a defect

Record usage.list_cost, the cap, active thread count, and the last request on every thread. A 50-cent cap can legitimately pause at 53 cents because the crossing request was admitted while cost was still below the cap.

Fail the canary if new model requests begin after the session is at the cap. Do not fail merely because a previously admitted request finishes above it.

4. Verify blocked and accepted events

At the cap, a new user.message must receive HTTP 400. Events that settle already-started work remain accepted: tool confirmations, tool results, custom tool results, and interrupts. A settled result must not silently trigger another model request.

This distinguishes “record the outcome of existing work” from “authorize more paid work.”

5. Test a controlled resume

Read the session's reported usage.list_cost, then raise the cap to at least one cent above that value plus the intended next-work allowance. Reusing the old cap can fail because enforcement uses exact unrounded cost while the API displays rounded cents.

Require an explicit operator record before the update:

Session ID:
Stop reason and last usage event:
Original cap / observed list cost:
Reason to continue:
New maximum:
Evidence the loop was fixed:
Approver / timestamp:

The accepted update resumes automatically. Do not send a duplicate user message “to restart” the task.

6. Test deployment and multiagent boundaries

For a scheduled deployment, start two canary sessions and prove each receives the same independent cap. Changing the deployment budget must affect only sessions created afterward.

For multiagent work, spawn the maximum approved concurrency, include an advisor if production uses one, and verify every thread shares the session cap. Advisor calls are charged to the same budget. If any selected model lacks a public list price, treat the budget path as unavailable rather than claiming a reliable cap.

Decision tree at `budget_reached`

Was the task already complete? Record the output and close the session without increasing the cap.
Is work waiting only on a tool result? Settle it; do not authorize another model turn yet.
Was there a retry loop, oversized context, or unexpected fan-out? Fix the cause and start a fresh bounded canary.
Is the remaining work known and valuable? Raise the cap once within the pre-approved maximum and record authority.
Is the required spend or outcome still uncertain? Leave the session idle and escalate to a human.

Pair this hard stop with AI Gateway spend attribution and the existing Managed Agents memory migration boundary. A session cap limits new spend; it does not explain which user, tool, or memory decision created the cost.

Common mistakes

Confusing list cost with the invoice. The enforcement meter uses public list rates even when contracted billing is lower.

Assuming zero overshoot. The platform stops between requests, not in the middle of one. Size for every active thread.

Removing a cap when you meant to raise it. Removal resumes work and prevents the same session from receiving another budget.

Treating a per-deployment budget as cumulative. The value is copied onto each new session. Track fleet-wide spend separately.

FAQ

Can I add a budget to a running session that started without one?

No. The API rejects that with HTTP 400. Create a new budgeted session instead.

Is `budget_reached` a completed task?

No. It means the platform paused new model work at the financial boundary. Evaluate the task outcome independently.

Does a task budget provide the same protection?

No. Managed Agents session budgets are hard, dollar-denominated platform caps. Messages API task budgets are advisory token budgets used by supported models to self-regulate, and they are not supported on Claude Code or Cowork surfaces.

Sources

Qwen Code 0.21.8 Workspace Trust Security Checklist

Ahab — Sun, 09 Aug 2026 01:19:27 +0000

Qwen Code 0.21.8: verify nested workspace trust before loading project env

Quick answer

Qwen Code 0.21.8, released August 8, 2026, fixes a workspace-trust precedence bug. Before the fix, a nested workspace explicitly marked DO_NOT_TRUST could still inherit TRUST_FOLDER from a parent. Qwen Code could then load the nested project's .qwen/settings.json or .env even though the user had rejected trust.

Version 0.21.8 changes the rule to most-specific path wins. Distrust also wins a same-depth tie, and the shared resolver is used by the regular CLI path, daemon policy, and qwen serve fast path. Upgrade every launcher, then prove the behavior with disposable sentinels before restoring auto-acceptance or unattended serving.

Do not read this as “every project-env boundary is fixed.” A separate, still-open change at publication time covers the reverse topology: a trusted child loading an .env from a distrusted ancestor. The rollout gate below tests both directions and fails closed if either sentinel crosses the boundary.

Who this is for

This guide is for developers who enabled Qwen Code Trusted Folders, keep multiple repositories under a trusted parent, run Qwen from subdirectories, or expose workspaces through qwen serve. The risk is highest when an automation assumes “Don't trust” means project settings and environment files cannot influence the process.

Trusted Folders is disabled by default. If you never enabled security.folderTrust.enabled, first decide whether the feature fits your workflow; installing 0.21.8 does not enable it automatically.

What changed in 0.21.8

The official Trusted Folders documentation says an untrusted workspace runs in safe mode: workspace settings and project .env files are ignored, extension management is restricted, tool auto-acceptance is disabled, and automatic memory loading is disabled. The bug made that promise inconsistent for nested paths.

Rule set	Workspace being opened	Before 0.21.8	0.21.8 expected result
`/projects` trusted; `/projects/vendor` distrusted	`/projects/vendor`	Could inherit trust	Untrusted
Same rules	`/projects/vendor/pkg`	Could inherit trust	Untrusted; deeper distrust contains the path
`/projects` distrusted; `/projects/owned` trusted	`/projects/owned`	Policy depended on duplicated resolution paths	Trusted; the more-specific rule wins
Equal-depth trusted and distrusted match	Matching descendant	Order-sensitive risk	Distrust wins
No matching rule	Unrelated workspace	Unknown / prompt path	Unchanged

The fix consolidates precedence into one resolver: compare every matching rule by path depth, choose the deepest, and prefer untrusted if two matches have equal depth. That removes persisted JSON insertion order from the decision.

Why project env loading makes this security-sensitive

The linked report demonstrated the impact through qwen serve. A nested repository could provide QWEN_SERVER_TOKEN through a project .env; if inherited parent trust won, the fast path could accept that value as the daemon bearer token. The issue also notes mitigating conditions: the user owns the central trust file, project env does not overwrite an already-set variable, and the default bind is loopback.

Those mitigations reduce exposure, but they do not make a failed distrust decision acceptable. The safer invariant is simple: a repository marked untrusted must not supply project settings, environment values, extensions, automatic memory, or tool-acceptance policy.

Six-canary rollout workflow

1. Upgrade every entry point

Inventory global npm installs, desktop or IDE launchers, CI images, daemon services, and long-lived shells. Then update the CLI and verify the binary each launcher resolves:

npm install -g @qwen-code/qwen-code@0.21.8
qwen --version

Do not infer a daemon upgraded because an interactive shell did. Restart persistent services after verifying their package path.

2. Snapshot intent without copying secrets

Use /permissions to review the current folder decision and inspect ~/.qwen/trustedFolders.json for conflicting parent and child rules. Record only paths and trust levels; do not copy project .env contents into the audit.

Build the lab with harmless names such as INDIESEEK_PARENT_SENTINEL and INDIESEEK_CHILD_SENTINEL. Never test with a production API key or daemon token.

3. Prove explicit child distrust

Mark a disposable parent TRUST_FOLDER and its nested repository DO_NOT_TRUST. Start Qwen from the nested repository and from a deeper packages/demo directory. Both runs must stay in safe mode and must not observe the child sentinel from .env or .qwen/settings.json.

This is the exact topology fixed by 0.21.8. Test the interactive CLI and qwen serve separately because both previously had their own resolution path.

4. Prove the reverse topology

Now mark the parent DO_NOT_TRUST and a child repository TRUST_FOLDER. Put different sentinels in the parent and child .env files. The child sentinel may load; the parent sentinel must not.

This catches a separate ancestor-walk boundary tracked by the open PR linked in Sources. If the parent sentinel appears, keep secrets out of project .env files, pass required values from the operator shell or service manager, and do not call the rollout complete.

5. Prove order and path parity

Repeat the two rule sets with their entries reversed in the disposable trust file. Results must not change. Also test the exact repository path, a descendant path, a symlink-resolved path used by your launcher, and the daemon workspace route. A UI badge is not enough; observe whether the sentinel was actually loaded.

6. Restore automation only after negative evidence

Re-enable extensions, auto-acceptance, background agents, or unattended qwen serve one control at a time. Keep the untrusted-repository sandbox checklist and MCP unknown-outcome reconciliation: workspace trust decides which configuration can load, not whether every loaded tool or write is safe.

Copyable acceptance record

Launcher / resolved qwen path / version:
Trusted Folders enabled: yes / no
Parent rule and path:
Child rule and path:
Exact child safe-mode result:
Descendant child safe-mode result:
Interactive project-env sentinel result:
qwen serve project-env sentinel result:
Reverse parent-env sentinel result:
Rule-order reversal result:
Symlink / canonical-path result:
Persistent service restarted:
Controls restored:
Owner and rollback trigger:
Decision: blocked / limited / accepted

Acceptance requires absence where data must not load. “The command started” or “the dialog looked right” is not boundary evidence.

Common mistakes

Upgrading only the terminal CLI. IDEs and daemons may resolve another installation and preserve the vulnerable behavior until restarted.

Testing only the exact nested folder. The 0.21.8 resolver intentionally applies the deepest rule to descendants. Test a subdirectory because agents often launch below the repository root.

Treating the release as a blanket env audit. The selected fix covers trust precedence. The reverse trusted-child/distrusted-parent env walk is a separate boundary and needs its own canary.

Using a real secret as the sentinel. The test asks whether a value crosses a boundary, not whether a credential works. Use disposable text.

FAQ

Does 0.21.8 automatically enable Trusted Folders?

No. The feature remains disabled by default and is enabled through the user setting security.folderTrust.enabled.

Should a trusted child override a distrusted parent?

Under the 0.21.8 most-specific-rule policy, yes: the deeper matching rule wins. That does not authorize loading the parent's own project .env; test each candidate directory separately.

Is this only a `qwen serve` issue?

No. The precedence decision affects regular workspace trust and daemon policy too. qwen serve makes the impact concrete because its fast path loads environment configuration before serving sessions.

DEV Community: Ahab

Grok 4.6 vs 4.5: Migrate Long-Running Agents by Accepted-Task Cost

Grok 4.6 vs 4.5: migrate long-running agents by accepted-task economics

Quick answer

Who this is for

What actually changed

Use a paired long-running task pack

Calculate accepted-task economics

A seven-gate migration workflow

1. Inventory every route

2. Freeze the 4.5 baseline

3. Prove the 4.6 API contract

4. Run the paired pack

5. Inspect trajectory growth

6. Verify partner availability separately

7. Ramp with explicit rollback

Decision tree

Common mistakes

Copyable decision record

FAQ

Is Grok 4.6 the same price as Grok 4.5?

Should every Grok 4.5 coding agent migrate?

Is Grok 4.6 available in GitHub Copilot everywhere?

Sources

Gemini 3.7 Flash vs 3.6: Migrate by Accepted-Task Cost

Gemini 3.7 Flash vs 3.6: migrate by accepted-task cost, not launch claims

Quick answer

Who this is for

What actually changed

Use a six-task accepted-result eval

A seven-gate migration workflow

1. Inventory every route

2. Remove incompatible request fields

3. Pin the exact model and lane

4. Route thinking deliberately

5. Run the paired fixture pack

6. Verify Copilot as a separate state machine

7. Ramp with rollback

Common mistakes

Copyable decision record

FAQ

Is Gemini 3.7 Flash more expensive than 3.6 Flash?

Should every Gemini 3.6 workload move to 3.7?

Does Copilot support Gemini 3.7 Flash everywhere now?

Sources

Qwen Code 0.21.11: Install Agent Plugins v1 Without Assuming Full Compatibility

Qwen Code 0.21.11: install Agent Plugins v1 without assuming every capability works

Quick answer

Who this is for

What changed in 0.21.11

Start with the real compatibility matrix

A seven-gate rollout workflow

1. Pin the client and package identity

2. Start at project scope

3. Prove native loading did not rewrite the package

4. Test supported and unsupported siblings together

5. Verify state and path containment

6. Run the HTTP credential canaries

7. Promote only the portable slice

Common mistakes

Copyable evidence record

FAQ

Can I install an Agent Plugin from GitHub or npm?

Why did the plugin install but its command or agent is missing?

Does allowed-tools pre-approve tools in Qwen Code?

Is legacy SSE MCP automatically upgraded to Streamable HTTP?

Sources

Claude Code 2.1.229: Keep Vertex and Bedrock Gateway Streams Alive

Claude Code 2.1.229: keep Vertex and Bedrock gateway streams alive during long thinking

Quick answer

Who this is for

What changed in 2.1.229

Map the five-layer path first

A six-step verification workflow

1. Prove the active version and route

2. Freeze one known-failing canary

3. Correlate one session across hops

4. Keep idle and total timeouts separate

5. Classify the result

6. Roll out and retain rollback evidence

Does `allowed-tools` pre-approve tools in Qwen Code?

Should I just increase `API_TIMEOUT_MS`?

Can I fix the failure by setting `CLAUDE_CODE_SUBPROCESS_ENV_SCRUB` to `0`?

Is `allowed_non_write_users: "*"` safe after the fix?