标签：#devto

A guide to formatting an RSS 2.0 feed so DEV.to imports your articles, images, and tags with zero formatting errors. 1. Quick Checklist: What to Do [ ] Wrap full article HTML inside <content:encoded><![CDATA[...]]></content:encoded> . [ ] Convert all image src , srcset , and link href attributes to absolute URLs ( https://domain.com/... ). [ ] Sanitize tags ( <category> ): alphanumeric only ( a-z0-9 ), max 20 chars, max 4 tags per post. [ ] Provide a unique <guid isPermaLink="true"> to prevent duplicate imports. [ ] Provide cover images via <enclosure> and as the first <img> inside <content:encoded> . [ ] In DEV Settings, keep "Mark RSS source as canonical" checked and "Replace self-referential links" unchecked. 2. RSS Field Reference <item> Fields Field Requirement What It Does on DEV.to <title> Required Article headline. Escape XML special characters. <link> Required Canonical link back to original post. <guid> Required Unique ID. Prevents re-importing duplicates on sync. <content:encoded> Required Full HTML body wrapped in <![CDATA[...]]> . Converted to Markdown by DEV. <description> Fallback Excerpt/summary. Used as body only if <content:encoded> is missing. <pubDate> Recommended UTC date ( Wed, 19 Aug 2026 10:00:00 GMT ). Sets publication/draft date. <category> Optional (Max 4) Becomes post tags. Must be alphanumeric and $\le$ 20 chars. <enclosure> Optional Sets the post's cover/hero image ( type="image/webp" or image/png ). <author> Optional email@domain.com (Author Name) 3. Strict Formatting Rules Rule 1: Tags ( <category> ) DEV.to rejects or corrupts tags that don't match [a-zA-Z0-9] : Remove special chars: next.js $\rightarrow$ nextjs , web-dev $\rightarrow$ webdev , c# $\rightarrow$ csharp . Truncate: Maximum 20 characters per tag. Limit: Maximum 4 tags per post. Rule 2: Images & Links (Must Be Absolute) DEV.to cannot resolve relative paths like /images/hero.png . ❌ <img src="/images/hero.png"> ✅ <img src="https://yourdomain.com/images/hero.png"> ❌ <a href

There is a small cluster of posts going around right now about auditing your LLM invoice, and about how cost calculators get the numbers wrong. I went to check mine and hit a problem before I got to the arithmetic: my pipeline doesn't produce an invoice, and the plumbing I built two months ago is the reason why. This project has a script, git_commit.py , that turns a staged git diff into a Conventional Commit message. It shells out to the Claude CLI. There is no ANTHROPIC_API_KEY anywhere in the project, on purpose — an early version used urllib against the API directly and broke immediately for anyone running on an OAuth session instead of a raw key, so every AI call in the repo goes through a claude -p subprocess instead. That decision is still right. It also means there is no API key, so there is no per-key usage dashboard, so there is no line item to audit. For several months this script has been making a model call on essentially every commit, and I have never once known what any of them cost. The call site throws the numbers away Here is the actual invocation, trimmed: raw = subprocess . check_output ( [ " claude " , " -p " , " --safe-mode " , SYSTEM + " \n\n " + diff ], text = True , timeout = 20 , env = _claude_subprocess_env (), ) subprocess.check_output returns stdout. With the CLI's default output format, stdout is the commit message string and nothing else. Every number I would want — tokens in, tokens out, dollars — is computed on the other side of that call and then discarded, because I asked for a string and a string is what I got. This is the part I want to flag for anyone wiring up a headless model call the same way. It isn't that the metering is missing. It's that the default output format is lossy in exactly the dimension you'd later want to audit, and you won't discover that by reading your own code, because your own code looks fine. It asks for text, it gets text. The fix is one flag: raw = subprocess . check_output ( [ " claude " , " -p " , " -

This week shipped one of the more consequential infrastructure changes in a while: DynamoDB absorbed vector search, collapsing a common two-database architecture into one. Meanwhile, a CMU study put hard numbers on something senior engineers have suspected about AI coding tools, and a 3B parameter model posted reasoning scores that have no business coming from a model that size. DynamoDB adds native vector search without a separate database AWS added a SearchVectors API to DynamoDB, letting you store embeddings alongside your application data and query them directly—no Pinecone, no Weaviate, no synchronization layer between your transactional store and your vector index. This matters because the dual-database pattern is genuinely painful at scale. You write to DynamoDB, you write to your vector DB, you manage consistency between them, you pay for two systems, and you debug failures in both. For RAG pipelines and semantic search on data that already lives in DynamoDB, that overhead exists purely because vector search wasn't available where your data was. Now it is. Setup requires picking an embedding model (Bedrock, Cohere, or OpenAI), configuring a vector index with dimensions and distance function, and rewriting retrieval queries to SearchVectors . Vector operations are billed separately per GB across writes, reads, and storage—so run the math before assuming this is cheaper than your current setup. Verdict: Ship if you're already on DynamoDB and maintaining a separate vector DB. The architectural simplification is real. Start with a proof-of-concept on a non-critical workload to validate cost and latency before migrating production RAG infrastructure. AI coding speed spike vanishes in three months Carnegie Mellon tracked 806 repositories after Cursor adoption and found that the velocity boost disappears by month three. What doesn't disappear: a 30% increase in warnings and 41% higher code complexity that persists indefinitely and cuts future velocity by 50–64%. Th

The warning landed on the only people who had done it properly I maintain a linter that reads agent config files — SKILL.md , AGENTS.md , CLAUDE.md — and fails CI when they bake in something that only works on the author's machine. One of its rules says: if you call an external CLI, declare it, or the next person won't have it. Declaring it means naming it in frontmatter: requires : codex Except that anyone with more than one dependency writes the list form, because that's what YAML is for: requires : - codex - gemini My implementation only read the first shape. So the block list — the normal way, the way you write it the moment you have two of anything — was invisible to the linter, and it warned you for an undeclared CLI that you had, in fact, declared. Read that back slowly. Authors who ignored the dependency question entirely were never flagged, because they never wrote a requires: key at all. Authors who sat down and wrote the contract properly got a warning telling them they hadn't. The rule was inverted with respect to the thing it was trying to encourage. I shipped that. It went out in a patch release, and I only found it because a commenter used the phrase "dependency contract" and I went to re-read my own implementation of it. Then it happened again. Twice, in one release Two comments on a post of mine turned into new rules. One of them, unverified-write , reports a file that changes external state — git push , npm publish , an INSERT — and never reads that state back anywhere. Before publishing, I ran it over 586 real skill files pulled from a public registry, found two false-positive shapes in the data, fixed both, and re-measured. Fire rate 0.7%, and every hit I could check by hand was genuine. I felt good about it. Then I handed the diff to a different model for a pre-publish read, and it produced this input in about a minute: Never run `git push --force` from this skill. That is a git push in a code span, in a file with no read-back anywhere. My rule

On 11 August the GoFullPage extension disappeared from the Chrome Web Store and got disabled in Chromium browsers. Eleven million users, one Tuesday. It was not a hack. The developers say it was a copyright dispute over a design element, that it was "definitively not a security issue", and that they are working with Google on getting it back. Chrome shows the same "might be unsafe" string for every kind of Web Store policy breach, so the warning read far worse than the cause. Two things came out of it. A short list of fixes, and a longer thought about where our tools live. Get working again in a minute Re-enable it. Open chrome://extensions . If Chrome disabled the extension rather than deleting it, the toggle is still there. Use Edge. GoFullPage was never removed from the Edge add-ons store. Install the beta. The team published a separate build at ID kehafhfdnkhdgbnpeofmhmbibmpnjaof , and it can sit alongside the original. That is the practical answer. The more interesting one is that most of us never needed the extension. Five ways to capture a full page with no extension at all 1. Chrome DevTools, no code Open DevTools, press Cmd/Ctrl + Shift + P , type screenshot , choose Capture full size screenshot . This has been in Chrome for years and most people have never found it. It handles scroll-height pages properly and drops a PNG in your downloads. 2. Firefox, even shorter In the Firefox console: :screenshot --fullpage Add --dpr 2 for a retina-density capture, or --clipboard to skip the file. 3. Chrome DevTools Protocol, if you want it scripted The thing the extension was wrapping is one CDP call: await client . send ( ' Page.captureScreenshot ' , { format : ' png ' , captureBeyondViewport : true , }); captureBeyondViewport is the flag that does the work. Everything else in a full-page screenshot tool is UI around it. 4. Playwright import { chromium } from ' playwright ' ; const browser = await chromium . launch (); const page = await browser . newPage ({ viewport

This week's tooling landscape is defined by two themes: cost compression on capable models and protocol-level standardization across agent runtimes. Gemini 3.7 Flash cuts inference spend while measurably improving first-pass code accuracy, and the AI SDK's ACP harness layer is quietly making multi-agent wiring less of a bespoke nightmare. Here's what's worth your attention. Gemini 3.7 Flash launches with coding performance gains Gemini 3.7 Flash ships at half the cost of 3.6 Flash with benchmark improvements that actually map to real workloads: FrontierCode jumps from 34.4% to 43.6%, and document reasoning on GDP.pdf goes from 22.0% to 34.0%. These aren't marginal deltas—a 9-point gain on code generation means materially fewer retries in agentic pipelines where each failed generation compounds latency and cost. For teams running Flash in production for code generation or document extraction, the math is straightforward: same API surface, half the token cost, better first-pass accuracy. Introductory pricing holds through year-end, so the window to lock in the savings is finite. Verdict: Ship. Drop-in swap via the Gemini API—no config changes required. If you're already on Flash for coding or document processing workloads, migrate now. The performance gains on code generation are large enough to reduce retry loops in multi-step planning tasks, which compounds into real infrastructure savings at scale. GLM 5.2 free for eve agents through August 27 Z.ai's GLM 5.2 is a 1M-token open-weights model now set as the default on eve agents, with free access through Vercel's AI Gateway until August 27. The 1M context window is the practical differentiator here—it's large enough to hold entire codebases in context for generation tasks that would otherwise require chunking or retrieval. The cost is zero during the trial window, and the integration is a one-line config change: set model: "zai/glm-5.2" in agent/agent.ts or run eve set --model zai/glm-5.2 . That's a trivially low bar

"Graphify turns codebases into queryable knowledge graphs. We designed a layered monorepo wiki extension — per-layer .graphify/ folders with staleness hooks — that doesn't exist yet. Here's the full spec and how to get 90% of it right now." Transparency note: This post describes a design pattern we invented on top of graphify , an existing open-source tool. The core tool is real. The layered wiki structure and .graphify/ folder convention described here are not official graphify features — they are a proposal. We'll clearly mark every invented part. The "how to approximate it today" sections use only real, working graphify commands. The Problem: One Graph, Many Layers If you haven't used graphify yet, the short version: you run /graphify . inside Claude Code (or graphify . --wiki from your terminal), and it turns your entire codebase into a queryable knowledge graph. Claude can then answer questions like "how does the checkout flow work?" or "what calls PaymentService?" with file-and-line citations instead of hallucinated guesses. It works brilliantly for single-service repos. But for a monorepo that looks like this: my-repo/ ├── frontend/ ← TypeScript / React ├── api/ ← Java / Spring Boot ├── services/ │ ├── order-service/ ← .NET / C# │ └── notification-worker/ ← Python └── database/ ← SQL stored procedures …you hit a wall. Run graphify . at the root and everything lands in a single flat graphify-out/ folder. The community articles generated by the --wiki flag end up mixing TypeScript React components with Java Spring controllers with SQL stored procedures. When you're deep inside the frontend layer fixing a component, Claude is also loading a wiki article about your database trigger — noise you don't need. The real question: what if each layer had its own scoped graph and wiki, colocated with the source it describes? The Concept: Layered Graphify Wiki ⚠️ Everything in this section is a design proposal — not official graphify. The folder names, behaviours, and some

I fixed this script's frontmatter parser a week ago. A draft with an unclosed --- block used to blow up with a bare ValueError: not enough values to unpack , and I patched it to raise a clean, actionable error instead. I wrote that fix up, verified it with a stubbed repro, added a --selftest case for it, called it done. Then I went back to write today's articles and actually looked at the line I "fixed" instead of the error path around it. def parse ( text ): meta = {} body = text if text . lstrip (). startswith ( " --- " ): parts = text . lstrip (). split ( " --- " , 2 ) if len ( parts ) < 3 : raise ValueError ( " frontmatter opened with ' --- ' but never closed with a second ' --- ' delimiter " ) _ , fm , body = parts ... split("---", 2) doesn't split on lines that are --- . It splits on the literal substring "---" , anywhere in the text, and stops after the second one it finds. My fix only handles the case where it finds fewer than two — an unclosed fence. It says nothing about what happens when the second "---" it finds isn't the closing fence at all, because a third one showed up first, buried inside a frontmatter value. That's not a hypothetical. I write these article titles myself, and "before/after" is a phrase I reach for constantly: --- title : My Before---After Refactor tags : ai, python, refactor published : true --- real body starts here split("---", 2) finds the em-dash-style --- inside the title before it finds the real closing fence on its own line. So the split points land in the wrong place entirely: >>> from publish_devto import parse >>> meta , body = parse ( text ) >>> meta { ' title ' : ' My Before ' } >>> body ' After Refactor \n tags: ai, python, refactor \n published: true \n --- \n real body starts here \n ' The title got truncated to "My Before" . tags and published never got parsed as frontmatter fields at all — they're sitting in the body now, as literal text, along with the real closing fence and a stray leftover --- . If I ran this thr

¿Tu equipo comparte credenciales por Slack? ¿Discuten arquitectura en plataformas que almacenan cada mensaje en servidores ajenos? Existe una alternativa que no depende de la nube: NETO . ¿Qué es NETO? NETO es un chat peer-to-peer diseñado para redes locales . No hay servidor central, no hay cuentas, no hay datos saliendo de tu oficina. Abres el navegador, y los compañeros de tu LAN aparecen automáticamente gracias a mDNS (Multicast DNS), el mismo protocolo que usa Bonjour para descubrir impresoras y servicios locales. Sin registro. Sin configuración. Sin fricción. Cifrado de extremo a extremo real Cada conexión entre peers se establece mediante WebRTC , creando canales de datos directos entre navegadores. Antes de intercambiar un solo mensaje, NETO realiza un intercambio de claves con X25519 (Curve25519 en

reply_comments.py is the script that tells me which DEV.to comments still need a reply. It walks every comment tree on every article I've published and reports the ones I haven't answered yet. I've fixed two bugs in it already: needs_reply() used to think a thread was "handled" forever after a single reply, even if the other person followed up again, and a dedup check was keyed on the thread's root comment instead of whichever message actually needed the reply, so a second round of conversation went permanently invisible. Both fixes are in --selftest now, and both looked, from the outside, like they'd covered this file's tree-walking logic pretty thoroughly. They hadn't. Today I found a third bug in the same handful of functions, and it survives even with both prior fixes applied. What the existing code assumes Comments on DEV.to come back from the API as trees. A top-level comment has a children list, and each child can have children of its own. The function that decides whether a thread needs attention is needs_reply() , built on latest_message() : def latest_message ( comment ): """ The most recently created message anywhere in this comment ' s subtree. """ latest = comment for c in comment [ " children " ]: candidate = latest_message ( c ) if candidate [ " created_at " ] > latest [ " created_at " ]: latest = candidate return latest def needs_reply ( comment ): return latest_message ( comment )[ " user " ][ " username " ] != ME This walks the whole subtree and returns exactly one message: whichever one has the latest timestamp, anywhere in the tree. _pending_entry() (the function pending() actually calls) is built directly on top of that single answer — it checks whether the latest message needs a reply, and if so, returns one entry for the whole thread. That's a reasonable design if a thread only ever grows one message at a time: root comment, my reply, their follow-up, my reply, and so on. Every test case in this file's --selftest , and both of the earlier bug

I have four different load_env() functions in my MCP server project ( my-git-manager ) — one in server.py , one in publish_devto.py , one in reply_comments.py , one in scripts/list_all_published_titles.py . All four exist for the same dumb reason: this repo has no dependency on python-dotenv , so each script that needs GITHUB_TOKEN or DEV_TO_API reads .env by hand. I went digging for a fresh bug in this repo this week — I write a lot about it, and the well is getting shallow — and decided to actually diff all four load_env() implementations against each other instead of reading them one at a time like I usually do. They'd never been compared side by side before. That's how I found this one. The line that started it Every one of them does roughly this: for line in f : line = line . strip () if " = " in line and not line . startswith ( " # " ): k , v = line . split ( " = " , 1 ) os . environ . setdefault ( k , v . strip (). strip ( '"' ). strip ( "'" )) Look closely at what gets .strip() ed there. v — the value — gets stripped of whitespace and surrounding quotes. k — the key, the actual name of the environment variable — gets nothing. That's fine if your .env file looks like this: DEV_TO_API = abc123 It's not fine if it looks like this: DEV_TO_API = abc123 Spaces around = are a completely normal thing to type. Plenty of .env examples online use them. Plenty of people reach for that style out of habit from other config formats. And line.split("=", 1) doesn't care — it splits on the first = no matter what's next to it, so k comes out as "DEV_TO_API " , trailing space included. What that trailing space actually does os.environ.setdefault("DEV_TO_API ", "abc123") sets an environment variable. It's just not the one anything is looking for. Every caller in this repo does os.environ.get("DEV_TO_API") — no trailing space, because that's the name everyone actually types. That lookup returns None , or whatever was already sitting in the environment before .env ever got read. I

Every mobile developer knows the frustration of "Design QA Day." You finish building a screen and send it to your UI/UX team or QA engineer. Then you receive a list of minor padding mismatch tickets. "This card padding should be 16dp, not 12dp." "The title baseline is slightly off on smaller device densities." Usually, fixing these issues means taking screenshots on devices, placing them onto a Figma canvas, lowering the opacity, and measuring pixels. You can streamline this entire process directly on your physical Android test devices using Designer Tools. Overlay Figma Comps Directly Over Live Apps Instead of comparing your app build side-by-side with a Figma preview on a monitor, you can overlay the target design file onto your screen using SYSTEM_ALERT_WINDOW permissions. Export your frame from Figma as a PNG. Load it into Designer Tools under Image Mockup Overlay. Set the opacity to 50%. When you open your app build underneath, any layout misalignment, incorrect text scaling, or constraint issue will become quickly visible as a drop-shadow ghost. Verify Density-Independent (dp) Grids Testing layouts across different device densities (mdpi, hdpi, xxhdpi) often results in unexpected spacing bugs. With the Custom Grid System in Designer Tools, you can create a grid native to dp: Set standard 4dp/8dp vertical and horizontal spacing grids. Set origin points (Top-Left, Center, or Safe Area bounds). You can verify component placement on target hardware instantly without manual measurements. Infinite Alignment Guides For measuring dynamic list items, headers, or bottom sheets, you can place interactive vertical and horizontal guidelines directly onto the active screen. This removes uncertainty about distances between different UI elements. Try It Out Designer Tools is lightweight and privacy-focused, as all image assets stay strictly on-device. It is built for Android engineers, QA teams, and UI designers. Download on Google Play: ( Pro Design: Designer Tools ) How doe

Your coding agent is a process that reads your filesystem and runs shell commands with your credentials. Most of the time that is exactly what you want. Occasionally it is cat .env while debugging - and now your production keys live in a transcript forever - or a confident rm -rf on a path that resolved differently than expected. Everyone's first fix is to add rules to CLAUDE.md: "never read .env, never force push". Those are suggestions to a language model. They work until they don't, and you will not be watching when they don't. Claude Code has a mechanism that is not a suggestion: hooks. A hook is a program you register for specific events - before a tool call, after it, when the session tries to end. It runs outside the model, sees the exact tool call as JSON on stdin, and its verdict is enforced by the harness itself. The model cannot talk its way past it, but it CAN read a structured denial and route around it productively. This is a cookbook for writing them. Everything below is plain Python stdlib and works on current Claude Code as of August 2026. The mechanics in ninety seconds Hooks are registered in settings ( .claude/settings.json in a project, ~/.claude/settings.json globally): { "hooks" : { "PreToolUse" : [ { "matcher" : "Read|Grep|Bash" , "hooks" : [ { "type" : "command" , "command" : "python3 \" ${CLAUDE_PROJECT_DIR}/.claude/hooks/secret-guard.py \" " , "timeout" : 10 } ] } ] } } The matcher filters by tool name. Your command receives a JSON object on stdin describing the event; for PreToolUse it includes tool_name and tool_input (the exact arguments about to run). You respond on stdout with JSON. Three responses cover almost everything: Deny a tool call, with a reason the model will read: { "hookSpecificOutput" : { "hookEventName" : "PreToolUse" , "permissionDecision" : "deny" , "permissionDecisionReason" : "why, and what to do instead" } } Block a session from ending (Stop event), sending work back: { "decision" : "block" , "reason" : "lint failed

The concrete problem Running two or three coding-agent sessions is easy. Knowing when their work is safe to combine is not. One session changes an API while another writes regression tests against the old shape. A third investigates a production failure and quietly edits the same configuration file. Git worktrees prevent immediate filesystem collisions, but they do not explain task dependencies, transfer assumptions, or warn that two agents are solving incompatible versions of the problem. The developer becomes a human message bus: checking terminals, copying commit IDs, repeating context, and deciding which session should wait. The more capable each agent becomes, the less useful a wall of terminal panes is as a coordination interface. The current signal Claude Code now supports messaging between sessions on the same machine. Its documentation describes session discovery, plain-text messages, and a local messaging socket. Agent view separately exposes background-session state, worktrees, pull-request status, and a JSON listing suitable for scripts. Hooks can observe tool input and block a tool call before execution. That does not prove demand for a new product. It does create a concrete implementation moment: the primitives for handoffs and visibility exist, while dependency ownership and conflict negotiation remain a workflow problem. In RayTally's bounded Hacker News snapshot at August 9, 00:33 UTC, the cross-session messaging discussion had 50 points and 26 comments and ranked 18th. Those numbers describe that historical observation only; they are not user counts, market validation, or a prediction of lasting interest. A product direction: a control desk for handoffs The useful product is not another chat window. It is a small local control desk that makes each session declare four things: its goal, worktree, files it expects to touch, and the result another session is waiting for. When the API session finishes, the testing session should receive a compact hando

Qarinah compiles a compact, cited project-memory pack instead of asking every new coding-agent session to replay the entire available history. The published estimate Across six committed software-task fixtures, the full-history baseline contained 442,113 portable estimated input-context tokens . The Qarinah path used 5,682 . Every required target was still directly covered in the top five results. That is: 436,431 fewer estimated input-context tokens; 98.71% less repeated context; and a 77.81:1 baseline-to-pack ratio. The ratio is not a claim that every provider bill drops by 98.71%, or that an agent session lasts 77.81 times longer. It measures the compared input-context volume in the published six-fixture estimate. What the same token rate would cost The table applies four flat, uncached input-token rates to the same two token estimates. It is arithmetic, not a provider invoice. Flat uncached input rate Full-history baseline Qarinah pack Estimated saving $1 / million tokens $0.442113 $0.005682 $0.436431 $3 / million tokens $1.326339 $0.017046 $1.309293 $5 / million tokens $2.210565 $0.028410 $2.182155 $15 / million tokens $6.631695 $0.085230 $6.546465 The calculation is: estimated tokens / 1,000,000 x flat input rate It deliberately excludes provider-native tokenization, caching, output tokens, reasoning tokens, tool calls, retrieval, hosting, and fixed fees. Real cost depends on the provider, model, cache behavior, context composition, and how often the same history would otherwise be resent. Why the pack remains useful Compression only matters if the next task can still find its evidence. The benchmark checks both volume and retrieval coverage: every required target had to be directly present in the top five. Qarinah preserves the source event ID and content hash for selected context, so a later agent receives a bounded handoff that can be inspected instead of an opaque story. Qarinah also passed 380 of 380 deterministic file-specific exact and typo-tolerant que

¿Tu equipo comparte tokens, contraseñas de staging o discute arquitectura sensible por Slack? Cada mensaje viaja a servidores de terceros. NETO es una alternativa radical: un chat peer-to-peer que funciona exclusivamente en tu red local, sin cuentas, sin nube, con cifrado de extremo a extremo. ¿Qué es NETO? NETO es una herramienta de mensajería diseñada para equipos de desarrollo que comparten la misma red. No hay servidor central, no hay registro, no hay datos que salgan de tu oficina o VPN. Abres la app y empiezas a hablar. ¿Cómo funciona por debajo? Descubrimiento con mDNS : NETO utiliza multicast DNS para encontrar automáticamente a otros peers en la red local. Sin configurar IPs ni puertos manualmente: si estás en la misma red, apareces. Cifrado con X25519 : Cada par de usuarios negocia claves efímeras mediante el

I have three files in this repo that shell out to something over the network or a subprocess and can fail in interesting ways: publish_devto.py , server.py , and git_commit.py . Two of them have --selftest blocks that stub the risky call and exercise the actual failure branches. One doesn't, and I only noticed because I went looking for a reason to be suspicious of my own test coverage after seeing a trending post about counting assertions in a test suite and not liking what you find. git_commit.py reads a staged diff and calls claude -p to turn it into a commit message. It has five distinct exit paths, all guarding real failure modes I've hit before in this project: try : diff = subprocess . check_output ([ " git " , " diff " , " --staged " ], text = True , timeout = 20 ) except subprocess . TimeoutExpired : print ( " git diff --staged timed out after 20s " , file = sys . stderr ) raise SystemExit ( 1 ) if not diff . strip (): print ( " Nothing staged. Run `git add` first. " ) raise SystemExit ( 1 ) try : raw = subprocess . check_output ( [ " claude " , " -p " , " --safe-mode " , SYSTEM + " \n\n " + diff ], text = True , timeout = 20 , stderr = subprocess . PIPE , ). strip () except subprocess . TimeoutExpired : print ( " claude -p timed out after 20s " , file = sys . stderr ) raise SystemExit ( 1 ) except subprocess . CalledProcessError as e : print ( f " claude -p exited { e . returncode } : { ( e . stderr or '' ). strip ()[ : 200 ] } " , file = sys . stderr ) raise SystemExit ( 1 ) except FileNotFoundError : print ( " claude CLI not found on PATH " , file = sys . stderr ) raise SystemExit ( 1 ) That's a held index lock hanging git diff , an empty staging area, a claude -p call that times out, one that exits non-zero, and one where the claude binary isn't even on PATH . Real scenarios — the timeout on this exact git diff --staged call was itself a bug I'd already found and fixed once ( docs/project_notes/bugs.md , 2026-08-06: a prior fix claimed to add a timeout

I have a small script, reply_comments.py , that pulls unanswered comments off my DEV.to articles and drafts replies to a markdown file so I can paste them in by hand. The API doesn't let a normal account post comments (that's its own bug I've written about before), so this draft-then-paste loop is the whole workflow. Every reply I've ever sent has come from reading the body field this script prints. Today I went looking for a bug distinct from everything already logged for this repo, and I ended up re-reading strip_html() , the function that turns a comment's raw body_html into the plain text I actually read: def strip_html ( h ): return re . sub ( r " \s+ " , " " , re . sub ( r " <[^>]+> " , " " , h )). strip () It does exactly one thing: strip HTML tags with a regex, then collapse whitespace. It's been in the file since the script was written and nobody had audited it on its own — every prior pass through this pipeline was about pagination, thread-depth walking, or dedup keys, never the text-extraction step itself. Here's the problem. DEV.to's API returns body_html as rendered HTML. A correct renderer has to HTML-entity-escape a commenter's own literal < , > , & , and quote characters, or they'd get mistaken for markup. So a comment that reads, in plain English: isn't it faster with a Q&A cache? Try List instead. comes back from the API as something like: <p> isn &#39; t it faster with a Q &amp; A cache? Try List &lt; String &gt; instead. </p> strip_html() 's regex only ever targets <[^>]+> — actual tags. It has no idea what to do with &#39; , &amp; , &lt; , &gt; . Those aren't tags, so the regex leaves them untouched. The whitespace collapse doesn't touch them either. What comes out the other end, into the exact field I read to draft a reply, is: isn&#39;t it faster with a Q&amp;A cache? Try List&lt;String&gt; instead. That's not a cosmetic nit. On a dev-focused comment section, & , < , and > show up constantly — generics, comparisons, "foo & bar," code snippets

Hoi hoi! I'm @nyaomaru, a frontend engineer who recently watched a flock of geese march through...

Anthropic shipped OS-level sandboxing for Claude Code. If you run an agent against a repo you care about, it's worth understanding precisely what moved — because a fair amount of the commentary treats it as "agents are contained now," and that's not what the documentation says. I read the docs carefully, partly because I build a tool in adjacent territory and needed to know whether I'd just been made redundant. Short answer: no. The longer answer is more interesting, and it starts with a compliment: the docs are unusually honest about their own limits. Most of what follows isn't something I discovered — it's something Anthropic wrote down, and more people should read it. What it actually does The sandbox uses OS primitives — Seatbelt on macOS, bubblewrap on Linux and WSL2. By default, sandboxed commands can write only to your working directory and the session temp directory. No network domains are pre-allowed: the first time a command needs a new host you're prompted, and approving it lasts the session. Crucially, this is enforced by the operating system on the running process , not by the model correctly interpreting a command. The docs put it well: the boundary holds regardless of what the model chose to run, and even if an allowed command does more than its name suggests. That's a real improvement over asking an agent nicely, and it's the right layer for what it solves. The motivation named in the docs is the same one I keep seeing in the wild: reducing the permission prompts that people stop reading. Approval fatigue is the disease; this is a real treatment for part of it. Five things worth knowing before you rely on it It's Bash-only. The sandbox constrains Bash commands and their child processes. Claude Code's own Read, Edit and Write tools don't run through it — they go through the permission system instead. "The sandbox is on" means shell commands are contained, not that every file operation is. Your working directory is inside the boundary by design. The de