Cantrip's pitch is that you never touch code. Then you open a website's settings, click into Advanced Coding, and find a full code editor waiting: dark theme, syntax highlighting, the works. Not a plain textarea. The kind of editor you'd expect in a code tool, dropped into a website builder built for people who supposedly don't want to see any code at all.
That contradiction is on purpose. Most people building a site on Cantrip never open that tab. The ones who do already know CSS and aren't looking for training wheels. So the box gives you exactly what you ask for and nothing more: paste in a rule, save, it goes live. No approval step, no formatting check. Nobody asks if you're sure.
Here's where that CSS lands. It gets dropped straight into a style tag in the page's head, after the theme's own stylesheet and after the handful of design variables (fonts, corner style, shadows) your theme sets. Loading last means ties go your way. It does not mean you automatically win. Nothing adds an !important flag to your rules, so a theme selector with higher specificity can still beat you outright. If a style you wrote refuses to take, that's usually why, not a bug, just the cascade doing its normal job. Open your browser's dev tools, check what's actually winning, and write a more specific selector.
One CSS box, one scope: the whole website. There's no per-page toggle. Want a rule to apply only to your contact page? You scope that yourself, with a page-specific class or ID, the same way you would on any hand-coded site. Cantrip doesn't do it for you.
Before you paste something huge in, know this: nobody checks it first. The tool that saves your CSS from the editor, and the same one an AI agent calls through Cantrip's MCP server, both accept whatever string you send with no length limit and no validation. There's a cap on the underlying API endpoint, but neither the editor nor the MCP path most people actually use goes through it. The real ceiling is the database column itself, and you won't get anywhere near that by accident. Break your own CSS and the page still loads. It just looks broken, and you won't know until you check the live site: there's no preview panel that shows you the damage before you hit save.
The output isn't sanitized either. Whatever you type renders exactly as written, same as the custom head code field a few tabs over. That's a deliberate trust call, not an oversight: this box exists for people who already know what raw output means. Anyone with access to your account can put anything they want into that tag, so treat account access here the way you'd treat FTP access to a hand-coded site, not a login you hand out casually.
One thing that might surprise you if you've switched themes before: custom CSS survives it. Change themes and Cantrip resets your font pairing, corner style, shadows, hover effects, and banner treatment back to that theme's own defaults. Your CSS box doesn't get touched. That cuts both ways. Good, because you don't lose work you wrote on purpose. Less good, because a rule you wrote to patch something in your old theme might now be fighting your new one in ways you don't expect. Check the CSS tab after a theme switch, not just the design settings.
None of this is a knock on the feature. Building a linter, a scoped preview, or a sandboxed version of this box would mean solving a problem the actual audience for it doesn't have. Somebody who opens Advanced Coding on Cantrip already writes CSS for a living, or close to it. Hand that person guardrails and you're just adding friction to the one part of the product built for people who don't want any.