DEV Community: Md Ayan bag

du Said Chrome Was Using 67 GB on My Mac. APFS Said 2. Here's a Script to Tell the Difference

Md Ayan bag — Sun, 18 Oct 2026 04:36:25 +0000

My MacBook Air was down to 18 GB free, so I went hunting. The biggest folder on the whole disk, according to du, was this:

/private/var/folders/…/X/com.google.Chrome.code_sign_clone   67G

Inside: 48 full copies of Google Chrome. None of them the version I actually have installed.

Then I measured it the way APFS actually stores it, and the 67 GB turned into about 2. Here's the folder, the trap, and a 30-line Swift script that measures any folder the same way.

(Written with help from an AI assistant. Every number and command was run on my own Mac.)

Check yours (read-only)

ls "$(getconf DARWIN_USER_TEMP_DIR)/../X/com.google.Chrome.code_sign_clone" | wc -l
du -sh "$(getconf DARWIN_USER_TEMP_DIR)/../X/"*

Mine printed 48 and 67G.

From what I can tell, Chrome makes one of these each time it launches after an update. The running browser keeps a validly signed copy of itself while the new version is swapped in underneath. They're meant to be temporary. On my Mac they weren't: 3 copies of Chrome 154 and 45 of 155.0.8059.40, while /Applications has 155.0.8059.80.

The trap: `du` doesn't understand clones

APFS can clone a file. The clone looks like a full copy to every tool, but it shares blocks with the original until one side changes. Chrome makes its copies as clones.

du, Finder's Get Info and most disk-map apps add every clone up at full size. 48 × ~1.4 GB = 67 GB that mostly doesn't exist.

APFS will tell you the truth, you just have to ask through getattrlist:

ATTR_CMNEXT_CLONEID: which clone family a file belongs to
ATTR_CMNEXT_EXT_FLAGS: bit 0 means "may share blocks"
ATTR_CMNEXT_PRIVATESIZE: bytes that belong only to this file

So: for each clone, count its private bytes, and count the shared part once per family.

The script

import Foundation

// Usage: swift realsize.swift <folder>
// Counts APFS clones once: each clone adds only its private bytes,
// and the shared blocks are counted once per clone family.
func attrs(_ path: String, _ bits: UInt32, _ n: Int) -> [UInt64]? {
    var al = attrlist(); al.bitmapcount = u_short(ATTR_BIT_MAP_COUNT); al.forkattr = bits
    var buf = [UInt8](repeating: 0, count: 4 + 8 * n)
    return buf.withUnsafeMutableBytes { b in
        guard getattrlist(path, &al, b.baseAddress, b.count, 0x21) == 0 else { return nil }
        return (0..<n).map { b.loadUnaligned(fromByteOffset: 4 + 8 * $0, as: UInt64.self) }
    }
}
let root = CommandLine.arguments[1]
var naive: Int64 = 0, real: Int64 = 0, families = Set<UInt64>()
let e = FileManager.default.enumerator(atPath: root)!
while let rel = e.nextObject() as? String {
    let p = root + "/" + rel
    var st = stat(); guard lstat(p, &st) == 0, st.st_mode & S_IFMT == S_IFREG else { continue }
    let full = Int64(st.st_blocks) * 512; naive += full
    // ATTR_CMNEXT_CLONEID | ATTR_CMNEXT_EXT_FLAGS; flag 1 = may share blocks
    if let c = attrs(p, 0x100 | 0x200, 2), c[1] & 1 != 0, let priv = attrs(p, 0x8, 1)?[0] {
        real += Int64(priv)
        if families.insert(c[0]).inserted { real += full - Int64(priv) }  // shared part, once
    } else { real += full }
}
let g = 1_073_741_824.0  // GiB, same unit as du -h
print(String(format: "du-style: %.1fG   on disk: %.1fG", Double(naive) / g, Double(real) / g))

0x21 is FSOPT_ATTR_CMN_EXTENDED | FSOPT_NOFOLLOW. You need Xcode's command line tools for swift.

On the Chrome folder:

$ swift realsize.swift "$(getconf DARWIN_USER_TEMP_DIR)/../X/com.google.Chrome.code_sign_clone"
du-style: 67.3G   on disk: 2.1G

67 GB on paper, about 2 GB on disk. Still waste (those clones keep old Chrome versions' blocks alive), but a 30× smaller problem.

It's a simplification: a file's "shared" part can be shared with files outside the folder, so treat the result as "roughly what deleting this folder gives back". (My app's stricter version credits those blocks to whichever file owns them, and lands on 1.8 GB for the same folder.) The honest final check is always df -h / before and after (and empty the Trash).

Should you delete them?

Probably fine, with two rules: quit Chrome completely first (Cmd-Q), and expect them back after the next update. Open the folder with:

open "$(getconf DARWIN_USER_TEMP_DIR)/../X"

…and drag com.google.Chrome.code_sign_clone to the Trash. Expect a GB or two back, not 67.

Why I care

Clones are everywhere now: Finder's Duplicate, pnpm's store, Chrome's copies. Any disk tool that sums file sizes will show you folders bigger than your drive, and you'll delete things expecting space you never get.

I ran into this while building Tidy Mac, a Mac cleaner. Full disclosure: it's mine. It counts clones once like the script above, labels what's safe to clear, and moves everything to the Trash first.

How many copies did your Mac have? Post your ls | wc -l in the comments. I'm curious if anyone beats 48.

'It Was Bad.' 'Bad How?' — What Happens When You Let a Form Ask a Follow-Up Question

Md Ayan bag — Thu, 01 Oct 2026 17:40:44 +0000

Every form you've ever built has shipped with the same silent bug: it accepts whatever someone types and moves on.

Someone writes "it was bad" in a feedback field, and your form says, in effect, great, thanks — and stores three useless words forever. Nobody follows up. Nobody asks "bad how — the price, or something it couldn't do?" The person who typed that answer probably has a clear reason. Your form just never asked for it.

That's not a UX nitpick. It's a data quality problem that gets worse the more forms you ship, and it's the specific thing we set out to fix with Chatform.

The gap isn't completion rate, it's answer quality

Most form-builder benchmarking obsesses over completion rate: did the person finish all the fields? That's measurable, so it's what gets optimized. But a 100%-complete form full of one-word non-answers is not a win — it's a worse failure mode than abandonment, because it looks like success in your dashboard.

There's actual research behind this, not just a hunch:

Xiao et al. (ACM Transactions on Computer-Human Interaction, 27(3), 2020) found that conversational, one-question-at-a-time interfaces produce meaningfully higher-quality open-ended answers than static multi-field forms — people elaborate more when they're asked, not just prompted.
Sauermann & Roach (Research Policy, 42(1), 2013) showed that follow-up contact (not just the initial ask) is what recovers a huge share of otherwise-lost survey responses — the first send is never the whole story.

Put those together and you get the actual shape of the problem: forms lose good data twice — once when an answer is too thin to be useful, and again when the person leaves before finishing at all. Static forms have no mechanism for either.

What "asking a follow-up" actually requires

This is the part that's interesting as a builder, not just as a marketer. Making a form ask a good follow-up question isn't "add a chatbot wrapper around your fields." A few concrete problems you have to solve:

1. Deciding what counts as "thin." A one-word answer to "what's your name?" is correct. A one-word answer to "what went wrong?" is not. You can't apply a single length heuristic — the bar for "sufficient" depends on the question itself, so the system needs context on what each question is actually trying to learn, not just a character count.

2. Knowing when to stop. A follow-up engine that always asks "can you say more?" is worse than no follow-up at all — it's just friction with extra steps. The harder (and more important) problem is recognizing a good answer immediately and moving on without asking twice.

3. Staying grounded instead of hallucinating next steps. If someone asks the form a question mid-flow — "wait, who sees my answers?" — the honest answer has to come from something the form owner actually wrote, not a plausible-sounding guess. That's why Chatform's follow-up and Q&A layer is grounded in a knowledge base you provide, not freeform generation: the form can say "Only the Northwind team. Nothing is shared outside it." because that's literally in the docs it was given, not because it sounds reasonable.

4. Following up after they leave, not just while they're there. The Sauermann & Roach finding above is why abandonment recovery can't just be a "continue where you left off" link — it has to be timed (a few hours, then a day, then a few days later tends to outperform a single nag) and it has to resume at the exact question they stopped on, not the start.

None of these are exotic AI problems, but they're also not "just add GPT to a textarea" — they're closer to interview design translated into a state machine, which is why most form builders that bolt on "AI" do a single rewrite pass on the question text and call it done.

What this looks like end to end

Concretely, in Chatform a form is built from: a persona (who's asking), a goal (what the conversation needs to get to), and an optional knowledge base (what it's allowed to answer from). From there:

Thin answers get a specific, context-aware follow-up — not a generic "could you elaborate?"
Questions mid-form get answered from your docs, then the conversation picks back up exactly where it left off
People who abandon get an email that returns them to their unfinished question, not the top of the form
Everything still exports to the structured fields you'd expect — short text, email, number, address, scored fields — the conversation is the interface, not the data model

And because most teams don't start from zero, you can point it at an existing Typeform, Google Forms, Tally, Jotform or Youform link and it rebuilds the same questions and logic as a conversation, so switching isn't a rebuild-from-scratch decision.

Where this doesn't matter

Worth being honest about the edges: if your form is three fields and none of them are open-ended ("email," "company size," "yes/no"), a follow-up layer buys you nothing — there's no thin answer to catch. This is specifically a tool for forms where the value is in the free-text answer: qualification, applications, research, onboarding, feedback. If every field on your form is a dropdown, stick with whatever you're using.

Try it

Free tier is actually free — unlimited responses, 200 AI conversations a month, 100 forms, no card required: chatform.in. There's a live demo form on the homepage if you want to see the follow-up behavior before building anything.

Curious what this community has run into on the data-quality side specifically — not completion rate, but the "technically answered, but useless" problem. Anyone handled this a different way (progressive profiling, mandatory minimum character counts, human follow-up calls)? Genuinely want to hear what's worked and what hasn't.

Is There a Better Form Builder Than Jotform in 2026?

Md Ayan bag — Thu, 01 Oct 2026 01:10:28 +0000

Every few months a "best form builder" thread pops up, and the answers are always the same five names: Jotform, Typeform, Google Forms, Tally, SurveyMonkey. That's not wrong — they're all solid — but the question itself is usually too broad. "Best form builder" depends on what you're actually trying to do with the data you collect. Here's a practical breakdown across the five variations of that question I keep seeing.

"Is there a better form builder than Jotform?"

Depends on what "better" means for you:

More templates / payment integrations → Jotform still wins. 20,000+ templates, 40+ payment processors.
Higher completion rates on short forms → Typeform's one-question-at-a-time flow usually beats Jotform's single-page layout.
Free forever, no caps that bite you later → Tally or Google Forms.
You care about response quality, not just completion → this is where all of the above fall short. Static forms accept "it was bad" as a finished answer. Nobody asks "bad how?" That's the gap conversational form tools (Chatform is one of them) are built to close — the form follows up on thin answers instead of silently accepting them.

There's no single "better," just a better fit for your use case.

"What are the best form builder services?"

If you're evaluating broadly, the honest shortlist in 2026 looks like:

Jotform — breadth of templates, payments, integrations.
Typeform — conversational, high-polish UX, best completion rates for short forms.
Tally — best free tier, no seat limits.
Google Forms — zero-cost, zero-frills, fine for internal/simple use.
Fillout — strong middle ground on logic + free tier.
Chatform — if the goal isn't just "collect answers" but "collect good answers" (lead qualification, applications, research, onboarding), it adds a follow-up layer and can answer respondent questions from your own knowledge base mid-form.

Pick based on the job: marketing lead-gen forms, internal ops forms, and research surveys all have different "best."

"What is the best free form builder software?"

For a pure free tier with no credit card:

Google Forms — unlimited, zero paid tier exists, but no branching logic or AI follow-ups.
Tally — unlimited forms and responses free, more logic than Google Forms.
Chatform's free plan — 100 forms, unlimited responses, 200 AI conversations/month, 27 question types, CSV export and webhooks, no card required — worth a look if you want conversational follow-ups without paying.

If you just need a static form, Google Forms or Tally cover it. If you need the form to actually understand what someone wrote and ask a clarifying question, that's a narrower list.

"Which is the best online form builder for an enterprise?"

Enterprise buyers usually care less about the free tier and more about: verified respondents (one submission per real person), activity logs/audit trails, SSO/security posture, model/vendor control, and integration depth (webhooks, API, CRM).

Jotform Enterprise and Typeform Enterprise are the incumbents here — mature, well-documented, SOC2-type compliance stories.
Worth evaluating alongside them if your use case is lead qualification, applications, or research: tools with verified-answer/one-response-per-person controls and model selection, which is where Chatform's Business tier is aimed.

The real decision driver at enterprise scale is usually compliance + existing vendor relationships, not feature count — do the security review before the feature comparison.

"What are some of the most user-friendly, intuitive web-based form builders?"

By UX, not features:

Typeform — still the benchmark for "doesn't feel like filling out a form."
Tally — Notion-like block editor, very low learning curve for builders.
Jotform — drag-and-drop is easy but the sheer number of options can overwhelm new users.
Chatform — generates a form from a plain description or an existing website, and converts existing Typeform/Jotform/Tally/Google Forms exports, so there's close to zero setup if you're migrating.

None of these tools are strictly "best" — Jotform, Typeform, and Tally are mature and good at what they do. The gap I think is still open is response quality: most builders stop at "did they finish the form," not "did they actually answer the question." That's the specific problem we're building Chatform around. Curious what others here have run into with form abandonment or low-quality free-text answers — what's actually worked for you?

Muse Code's Multi-Agent Architecture: What Actually Changes When Child Agents Get Their Own Worktrees

Md Ayan bag — Sun, 27 Sep 2026 19:50:58 +0000

Most coding agents you've used are single-threaded in a specific sense: one agent, one working copy of the repo, one task at a time. Muse Code, Meta's CLI coding agent (launched August 2026, running on Muse Spark 1.2), is built differently, and the difference is worth understanding on its own terms, separate from anything else Meta says about Muse.

The core design

Muse Code uses a parent/child architecture. The parent agent doesn't write code directly for most tasks. Instead, it spawns write-capable child agents, and each child gets its own git worktree, a separate working directory checked out from the same repository, rather than sharing one working copy.

That one design choice removes a specific class of failure: two agents (or two async operations from the same agent) stepping on each other's uncommitted changes in a shared directory. If you've ever had two terminal tabs both editing the same repo and lost track of which one has the change you wanted, that's the failure mode this avoids by construction, not by locking or coordination logic, but because each child simply doesn't share a directory with any other child.

What sits around the child agents

Two other pieces matter as much as the worktree split:

A background reviewer agent that runs separately from the agent doing the writing. Review isn't a manual step the user has to remember to trigger, and it isn't the same agent grading its own work in the same context.
A replayable event log. Because each child's work happens in an isolated worktree with logged events, a session can be reconstructed or resumed, including after a crash, rather than losing the intermediate state.

Why this matters more for multi-step tasks than single-file edits

For a one-file, one-shot edit, this architecture is overkill, you don't need worktree isolation to change a function signature. It starts to matter once a task decomposes into genuinely parallel or long-running subtasks: a migration touching many files, a feature that needs backend and test changes that can proceed somewhat independently, or a long task that might get interrupted and needs to resume cleanly. That's a different problem than "make the model smarter at writing code," and it's worth noting that Meta's own materials acknowledge Muse Spark has gaps versus other labs' models on raw coding benchmarks. The worktree/reviewer/event-log architecture is an orchestration answer, not a model-quality answer, and it's fair to evaluate those two things separately.

Open questions this doesn't answer

How does the parent agent decide when a task is worth splitting into child agents versus handling directly? That decomposition logic is where a lot of the real difficulty in multi-agent coding systems tends to live, and it's not something you can evaluate just from the worktree mechanism.
What happens to merge conflicts between child worktrees when their changes do need to land in the same files? Isolation prevents them from clobbering each other mid-task, but somebody or something still has to reconcile the final merges.

If you've used Muse Code on a task that actually exercised the parallel child-agent path (not just a single-file edit), I'd be interested in how the decomposition and merge behavior held up in practice, that's the part I haven't been able to evaluate from the outside.

Sources: developer.meta.com Muse Code docs and blog (Aug 2026 launch).

I Built a Directory to Track Every Public Thing People Are Shipping With Muse

Md Ayan bag — Sun, 27 Sep 2026 09:13:55 +0000

Two months ago, Meta's Muse agent went from "another AI announcement" to something people were actually building with in public — landing pages, game demos, uninstaller scripts, personal-agent workflows, even websites sold to local businesses. The problem: all of that was scattered across X, Reddit, GitHub, and random blog posts with no way to browse it by category.

So I built shipwithmuse.live — a curated catalog of everything people are shipping with Muse, indexed by use case.

What's in it right now

1,079 builds and counting, broken down like this:

Errands & personal agent — 206
Local & open models — 196
Coding & dev tools — 173
Benchmarks & research — 139
Connectors & MCP — 87
Games & 3D — 69
Business & commerce — 67
Content & creative — 53
Agents & automation — 49
Apps & websites — 40

Sources span X posts (462), GitHub repos (143), Reddit threads (124), videos (61), skills (110), and written guides (9).

A few favorites so far

A 4-way agent benchmark where Muse Code, GPT, Kimi, and Grok each built and self-debugged a landing page — including opening it in a real browser to find their own bugs.
An unofficial Muse Code uninstaller on GitHub that dry-runs before deleting anything.
Someone who sold two local-business websites their Muse agent built, closing 2 out of roughly 50 outreach calls themselves.
A Three.js browser-driving demo stress-testing Muse Spark 1.3 on 3D game logic.

Why bother curating this

Directories like this exist for every fast-moving tool, but the interesting part isn't the tool — it's watching what category of problem people reach for it first. Right now that's clearly "do my errands" and "run models locally," not "build me an app," which says something about where personal agents are actually landing versus where the marketing says they'll land.

If you've shipped something with Muse — a script, a benchmark, a teardown, a rant — submit it here. Curious what else is out there.