DEV Community: Im Woojin

I made my Markdown Editor "AI-Ready": MarkSmith v0.3.0

Im Woojin — Thu, 28 May 2026 18:51:39 +0000

Hey DEV community! 👋

A few days ago, I built a VS Code extension called Marksmith to fix the most annoying parts of writing Markdown (like pasting Excel tables and syncing preview scrolls).

But recently, I noticed a huge shift in my own workflow: Half the Markdown I write isn't for humans anymore. It’s being fed directly into Claude, ChatGPT, or Gemini as prompts and context.

When you're constantly stuffing docs into context windows, two things happen:

You worry about hitting context limits (or racking up API costs).
You waste time dealing with AI "hallucinations" when you ask it to generate docs back for you.

So, for the v0.3.0 release,
I decided to pivot Marksmith into something new: An Agent AI-Ready Markdown Toolkit. 🚀

Here is what I added to survive the AI era:

📊 1. Real-time LLM Token Estimator

Instead of just counting words, Marksmith’s Document X-Ray sidebar now includes a Heuristic Token Estimator for GPT, Claude, and Gemini.

Before you copy-paste that massive README into your AI assistant, you can see exactly how "heavy" it is in terms of tokens right inside your editor. No more guessing if you're about to blow past your context limit!

✂️ 2. Copy Optimized for AI (1-Click Minify)

Formatting is great for humans, but LLMs don't need all those extra spaces, perfectly aligned markdown tables, or empty lines.

I added a CodeLens button at the top of your files. Click it, and Marksmith instantly minifies your Markdown (compresses tables, strips blanks) and copies it to your clipboard.
Result: You save significant tokens and API costs without ruining your beautiful local .md file.

🕵️ 3. Hallucination Quick Fix

Ever ask an AI to write documentation, and it leaves behind a bunch of [TODO: Insert link here] or makes up a fake local image path?

Marksmith now automatically scans your document and puts a red squiggly line under AI placeholders and broken local links. Click the 💡 icon, and you can instantly strip them out or fix them. It acts as a safety net before you commit AI-generated docs.

🛡️ 4. Security Hardening (SSRF / RCE blocked)

Wait, security in a Markdown extension? Yes!
If you are previewing AI-generated Markdown, you are essentially rendering untrusted input. Maliciously crafted Markdown can trigger SSRF (Server-Side Request Forgery) by trying to fetch internal network metadata, or even execute code during PDF exports.

I completely locked down the extension. It uses strict DOMPurify sandboxing and actively blocks attempts to ping internal/cloud IPs.

🎨 Bonus: A 90s Retro Redesign

Because coding should be fun, I spent the weekend completely rebuilding the landing page using a Mac OS Classic / Neo-Brutalism theme. Let me know what you think of the vibes! 💾

🌐 Open VSX / Cursor Support

For all my Cursor, Windsurf, and VSCodium users out there—thank you for the support! The extension has been doing surprisingly well on Open VSX, and it's officially verified there too.

👇 Check it out here:

🖥️ Website & Demo: rakkunn.github.io/MarkSmith
🐙 Source Code: GitHub Repository

It is 100% free and open-source. If you are building with AI or just write a ton of docs, I hope this saves you as much time as it saves me.

Would love to hear your feedback in the comments! Happy coding! 💻✨

Building Marksmith: lessons from making Markdown bearable in VS Code

Im Woojin — Sun, 24 May 2026 10:04:35 +0000

I'll start with the moment that pushed me to build this.

I was editing a 1,200-line README. Spotted a typo in the preview pane. Scrolled the source to find it. Lost my place. Scrolled more. Pasted a table from a Google Sheet and got back a wall of tab characters. Closed VS Code in frustration and went to make coffee.

That week I started building Marksmith, a VS Code extension that tries to fix the small things that quietly drain you when writing Markdown. This is a retrospective: what I shipped, the parts that were harder than expected, and the security work that ended up being the largest chunk of the project.

The problem isn't Markdown — it's the workflow around it

The syntax is fine. The friction lives next to it:

Pasting a table from Excel or Sheets gives you tab-separated garbage
Pasting a URL means manually typing [text](url)
Editor and preview scroll independently, so a long file turns into needle-in-haystack
You have no idea how heavy your doc is until you paste it into Claude or GPT and watch the token count blow up

Each one is small. Together they're death by a thousand context switches.

Smart Paste: making the clipboard do the work

The first thing I built was clipboard interception. When you paste, Marksmith inspects the clipboard before VS Code's default handler runs:

async function handlePaste(clipboardText: string, editor: TextEditor) {
  // Tab-separated, multi-line → Excel/Sheets table
  if (isTabularData(clipboardText)) {
    return convertToMarkdownTable(clipboardText);
  }

  // URL pasted over a text selection → auto-link
  if (isURL(clipboardText) && !editor.selection.isEmpty) {
    const selected = editor.document.getText(editor.selection);
    return `[${selected}](${clipboardText})`;
  }

  return clipboardText;
}

The Excel-to-Markdown conversion is the one users mention most. It's not complicated — split by tabs, normalize column widths, generate the |---| separator. But the impact on writing flow is disproportionate to the implementation effort.

Bi-directional sync: scrolling that actually works

This one took a few iterations.

The first version synced scroll position by percentage. Useless for long files, because Markdown blocks have wildly different rendered heights (a one-line image reference is tiny in source, huge in preview).

The fix was source-mapping. When rendering Markdown to HTML, attach a data-line attribute to every top-level element pointing back to the source line:

<h2 data-line="42">Bi-directional sync</h2>
<p data-line="44">This one took a few iterations.</p>

Scroll handlers on both sides then walk the DOM and align based on those anchors. Clicking any element in the preview jumps the cursor to that source line. Not novel — most modern Markdown editors do something similar — but getting it smooth inside a VS Code webview took some debouncing to avoid feedback loops where each side's scroll event triggered the other infinitely.

Document X-Ray: knowing the cost before you paste

If you draft in Markdown and feed it to an LLM, you eventually hit context limits. Marksmith has a sidebar showing word count, readability score, and an estimated LLM token count.

The token estimate is a heuristic — running a real tokenizer in the extension host would be too heavy on every keystroke. Instead it uses a character-and-whitespace approximation calibrated against tiktoken output on a documentation corpus. It gets within ~5% on doc-style text, which is enough to catch "this prompt is too big" before you actually paste it somewhere.

I'd like to move this to a real tokenizer in a worker thread eventually. For now the heuristic is good enough.

The part I underestimated: security

I thought I was building an editor extension. I ended up spending more time on security than on features. Three classes of vulnerability mattered:

XSS in the webview. Markdown allows raw HTML, so a <script> tag in someone's README would execute in the webview context. I run all rendered HTML through DOMPurify with a strict allowlist, while preserving the elements I actually want (Mermaid SVG, syntax-highlighted spans):

const sanitized = DOMPurify.sanitize(html, {
  ALLOWED_TAGS: [...defaultTags, 'svg', 'path', 'g', 'rect', 'text'],
  ALLOWED_ATTR: [...defaultAttrs, 'data-line', 'viewBox', 'xmlns'],
  FORBID_TAGS: ['script', 'style', 'iframe'],
});

RCE through PDF export. Marksmith uses Puppeteer to render to PDF. In the first version I hadn't verified the Chromium sandbox was actually engaging on user machines. A crafted Markdown file with malicious HTML could, in theory, escape the renderer. I now explicitly verify sandbox mode at launch and fail closed if it isn't available.

SSRF in URL preview. Smart Paste optionally fetches the title of a URL you paste. Without filtering, a user could be tricked into pasting http://169.254.169.254/... (the AWS metadata endpoint) or http://192.168.1.1/admin, and the extension would dutifully fetch it. The fix is IP filtering before the request, plus a redirect cap:

async function safeFetch(url: string) {
  const { address } = await dns.lookup(new URL(url).hostname);
  if (isPrivateIP(address) || isLoopback(address)) {
    throw new Error('Blocked: private/loopback address');
  }
  return fetch(url, { redirect: 'manual', /* + cap follows */ });
}

None of this is novel security work. What surprised me was how much attack surface a "simple" Markdown extension exposes once it starts being helpful — fetching URLs, rendering arbitrary HTML, spawning headless browsers.

What I'd do differently

A few things in hindsight:

Threat-model first, features second. I retrofitted protections; should have designed for them from day one.
The token counter should have been a worker from the start. Moving it off the main thread later was awkward and broke a few assumptions in the sidebar UI.
Test on Windows earlier. Path handling for PDF export gave me grief that I could have caught much sooner.

Try it

Source: Github
Homepage: Marksmith
VSCode Marketplace: Marksmith on VS Code Marketplace
OpenVSX Marketplace: Marksmith on OpenVSX

If you've shipped a VS Code extension and have war stories about webview security or Puppeteer sandboxing, I'd genuinely like to hear them — drop a comment.

DualClip v1.2.6 — Stability Fix, Homebrew

Im Woojin — Tue, 14 Apr 2026 07:57:34 +0000

It's been a busy couple of days for DualClip. What started as a frustrating crash investigation turned into a series of meaningful improvements — from fixing a deep resource-bundling bug to shipping Homebrew support. Here's a rundown of everything that changed.

The Crash That Wouldn't Quit

Shortly after v1.2.0, DualClip started crashing on launch for some users. The crash report pointed to Bundle.module inside the KeyboardShortcuts dependency — a fatalError triggered because the app couldn't locate its resource bundle at runtime.

The root cause turned out to be a subtle mismatch in how Swift Package Manager bundles resources for standalone .app builds:

SPM generates a file called resource_bundle_accessor.swift that looks for resources at Bundle.main.bundleURL — which resolves to the .app/ root directory.
But macOS codesigning requires all resources to live inside Contents/Resources/, not the app root. Placing bundles at the root causes an "unsealed contents" signing error.
So the resources were in Contents/Resources/, but the code was looking at .app/ — and finding nothing. The fix was surgical: after the initial build, we patch the generated accessor to use Bundle.main.resourceURL! (which points to Contents/Resources/), then recompile just the affected module and re-link the executable. SPM regenerates the accessor on every full build, so we had to carefully avoid triggering a rebuild after patching. The final binary is verified with strings to confirm the patch is baked in.

This fix ships in v1.2.6 and the crash is fully resolved.

Homebrew Support

DualClip is now installable via Homebrew:

brew install RAKKUNN/tap/dualclip

We set up a dedicated Homebrew Tap with a Cask formula that points to the latest signed and notarized release. The CI pipeline automatically updates the formula (version + SHA256) whenever a new release is tagged — zero manual steps.

What Makes DualClip Different

After analyzing 57 macOS clipboard managers, one thing stood out: every single one is a clipboard history manager. DualClip is the only one that uses dedicated slots.

The difference matters:

History managers record everything you copy and let you scroll back through it. Great for recall, but adds complexity — databases, search UI, sync, storage limits.
DualClip gives you 3 fixed slots with instant keyboard access. You decide where to copy, not when to find it later. No history, no scrolling, no search.
It's also one of the few clipboard tools that stores absolutely nothing to disk. Everything lives in RAM and vanishes on quit. No network access, no telemetry, no cloud sync.

Try It

brew install RAKKUNN/tap/dualclip
Or grab the latest release from GitHub.

RAKKUNN / DualClip

A lightweight macOS app for multi-slot clipboard management

DualClip

English · 한국어 · 日本語 · 中文

A lightweight macOS menu bar app that provides multi-slot clipboard management.
Unlike history-based clipboard managers, DualClip gives you instant access to dedicated clipboard slots via customizable keyboard shortcuts

🌐 Website · ⬇ Download · 🍺 Homebrew

Features

3 Clipboard Slots: Slot A (system default), Slot B, and Slot C
Customizable Shortcuts: No hardcoded key conflicts — configure your own shortcuts
Atomic Paste: Seamlessly pastes from any slot without corrupting your system clipboard
Menu Bar Popover: Quick-glance view of all slot contents with previews
Privacy First: All data lives in RAM only — nothing is persisted to disk
Zero Network Access: No telemetry, no analytics, no internet communication

Demo

Default Shortcuts

Action	Shortcut
Copy to Slot B	⌥⌘C
Paste from Slot B	⌥⌘V
Copy to Slot C	⌃⌘C
Paste from Slot C	⌃⌘V

All shortcuts are…

View on GitHub

Signed and notarized by Apple — no Gatekeeper warnings.

DualClip is open source under the MIT license. Issues, feedback, and contributions are welcome.

Thank you, have a nice day!

DualClip - Update_2026.04.12.

Im Woojin — Sun, 12 Apr 2026 07:48:23 +0000

Last week, I shared the first round of updates for DualClip, my open-source macOS clipboard manager. Since then, I’ve crossed off three major items from the roadmap—including the one I’m most excited about: you can finally download DualClip without needing to build it from source.

Here is the breakdown of what’s new in v1.1.0.

🔒 Secure Input Field Detection

This was at the top of my "What’s Next" list for a reason: Privacy.

When macOS has a password field focused, the system activates a mode called Secure Event Input. DualClip now checks for this state before every copy and paste operation. If you're typing a password into Safari, 1Password, or a terminal sudo prompt, DualClip silently steps back.

Swift
func isSecureInputActive() -> Bool {
    return IsSecureEventInputEnabled()
}

The guard is dead simple—one line in handleCopy and one in handlePaste:

Swift
guard !AccessibilityService.shared.isSecureInputActive() else { return }

It’s the kind of feature that, when it works correctly, you never notice. And that’s exactly the point.

📦 Prebuilt Binaries (No Xcode Required!)

The biggest friction point in my original post was: "There's no prebuilt binary yet." Starting with v1.1.0, every release is signed with a Developer ID certificate and notarized by Apple. This means:

No more Gatekeeper warnings.
No "Open Anyway" dance in System Settings.
Just download, drag to Applications, and go.

🏗 The CI/CD Saga: 3 Bugs and a Notarization Pipeline

Getting the automated release pipeline working was... an adventure. I’m using GitHub Actions to handle the heavy lifting. The workflow triggers on version tags (v*..) and follows this sequence:

Build: swift build -c release on a macOS 14 ARM runner.
Import: Decode the .p12 certificate from GitHub Secrets.
Bundle: Assemble the .app structure.
Sign: codesign with hardened runtime and a timestamp.
Notarize: Submit to Apple, poll for completion, and staple the ticket.

Sounds clean on paper. In practice, it took four attempts and taught me three very humbling lessons:

Bug 1: The One-Character Typo
I spent 10 minutes staring at a 401 Unauthorized error from Apple’s API. It turned out to be a typo in my app-specific password secret: fjhk vs tihk. CI/CD reminds you that your eyes see what they want to see, not what’s actually there.

Bug 2: The Service Outage
Three consecutive submissions got stuck at "In Progress" for hours. I thought my script was hung. It turns out Apple's notarization service was actually having a global outage. Even the best pipeline can’t fix a broken cloud.

Bug 3: The awk Failure
My polling script used awk '{print $2}' to extract the status from notarytool info. However, the status string for a pending job is In Progress (two words). awk captured only "In," which matched nothing in my logic.
The Fix: Switched to sed 's/.*status: //' to grab the full string.

🔄 Updated Roadmap

Feature Status
Secure input field detection ✅ Shipped
RAM zeroing on termination ✅ Shipped
Image/rich text support ✅ Shipped
GitHub Actions CI/CD + Notarization ✅ Shipped
Homebrew Cask distribution 🔜 Next
Sparkle auto-update 📅 Planned

Try it out

If you’ve been waiting for a downloadable build, it’s ready for you:

Go to the Latest Releases.
Download DualClip-1.1.0-arm64.zip.
Unzip, move to Applications, and launch.
Grant Accessibility permission when prompted.

🔗 GitHub: https://github.com/RAKKUNN/DualClip

If you find a bug or have a feature request, feel free to open an issue or a PR!

DualClip - Update_2026.04.04.

Im Woojin — Sat, 04 Apr 2026 10:54:46 +0000

DualClip Update — Beyond Text, and a 150ms Correction

A few hours ago, I shared DualClip, a slot-based clipboard manager for macOS. Thank you to everyone who checked it out!

Since then, I've shipped a few meaningful updates that I didn't cover in the original post. I also owe you a small correction. Let me walk through both.

🔧 First, a correction: 50ms → 150ms

In my first post, I wrote that the Atomic Paste operation completes "in less than 50ms." That was wrong. The actual restore delay is 150ms.

/// 150ms is an empirically safe value to prevent race conditions.
private let restoreDelayMs: Int = 150

150ms was chosen empirically to avoid a race condition — if the clipboard is restored before the target application finishes reading it, the paste silently fails. 50ms sounded cooler, but 150ms is what actually works reliably. Sorry about that.

⚡ How Atomic Paste actually works

Since this is the core mechanic of DualClip, I figured it deserves a proper breakdown. When you press the hotkey to paste from Slot B, here's what happens under the hood:

1. Backup — The entire system clipboard (Slot A) is deep-copied into a temporary buffer. Not just text — all NSPasteboardItem types and their raw data.

2. Swap — Slot B's content is written to the system clipboard, replacing whatever was there.

3. Simulate — A CGEvent-based ⌘V keystroke is posted to the HID system. This is why DualClip requires Accessibility permission — it's literally pressing keys on your behalf.

4. Restore — After 150ms, the backup is written back to the system clipboard. Your original ⌘C content is untouched.

The entire flow is invisible to the user. You press a hotkey, text appears, and your clipboard stays exactly as it was.

🖼 Multi-content type support

The first post only showed text workflows, which gave the impression that DualClip is text-only. It's not — it now supports four content types:

Type	Example
Plain text	Code snippets, URLs, API keys
Rich text (RTF)	Formatted text with bold, colors, etc.
Images	Screenshots, design assets from Figma
File URLs	File paths copied from Finder

Each slot stores the raw NSPasteboardItem data faithfully, so what you copy is exactly what you get back — formatting, metadata, and all.

This means you can now keep a screenshot in Slot B and a HEX code in Slot C, then paste them alternately into your editor without touching the mouse.

🔐 RAM Zeroing on termination

In the first post, I mentioned that all data lives in RAM only. That's still true, but I've taken it a step further.

When DualClip quits, it doesn't just release memory — it overwrites every byte with zeros before deallocation:

func secureWipe() {
    if let items = pasteboardItems {
        for item in items {
            for type in item.types {
                if let data = item.data(forType: type) {
                    data.withUnsafeBytes { rawBuffer in
                        guard let baseAddress = rawBuffer.baseAddress else { return }
                        let mutable = UnsafeMutableRawPointer(mutating: baseAddress)
                        memset(mutable, 0, rawBuffer.count)
                    }
                }
            }
        }
    }
    clear()
}

This is called on applicationWillTerminate for all three slots. If you temporarily stored an API key or password in a slot, it won't linger in physical memory after the app closes.

To summarize the privacy model:

No disk writes. Nothing is persisted.
No network. Zero external communication.
RAM zeroing. Memory is scrubbed on exit.
Open source. You can verify all of the above yourself.

🏗 CI pipeline

I've added a GitHub Actions workflow that runs on every push and PR to main. It builds the project in both Debug and Release configurations on macOS 14 with Swift 5.9.

It's a simple setup — no notarization or automatic releases yet — but it catches build regressions before they land.

🛠 Building from source

There's no prebuilt binary yet, but building is straightforward if you have Xcode:

git clone https://github.com/RAKKUNN/DualClip.git
cd DualClip
open Package.swift

Hit ▶ Run in Xcode. On first launch, macOS will ask for Accessibility permission — this is required for the CGEvent keystroke simulation that powers Atomic Paste.

What's next

Secure input field detection (auto-disable in password fields)
Homebrew Cask distribution
Sparkle auto-update

This is still a small, single-purpose tool, but I'm trying to get the details right. If you have feedback or want to contribute, the repo is open.

🔗 GitHub: https://github.com/RAKKUNN/DualClip

Thanks for reading!

DualClip: multi-slot clipboard manager for macOS

Im Woojin — Fri, 03 Apr 2026 23:09:10 +0000

First project with macOS & Swift

I wanted to share DualClip, a native macOS menu bar app I’ve been working on.

While there are many great clipboard managers like Maccy or Paste, I found that most of them focus on "History"—searching through a vertical list of everything you've copied.

I built DualClip because I needed something that works more like a "Workbench." Instead of picking from a menu, DualClip gives you dedicated slots (A, B, and C) that you can access instantly via global hotkeys.

🚀 How it differs from history-based managers:

No List Selection: You don't have to break your flow to search or click an item from a list. You use ⌥⌘C to save to Slot B and ⌥⌘V to paste it instantly.

Atomic Paste: When you trigger a secondary slot, the app performs a high-speed "injection"—swapping the system clipboard, pasting, and restoring the original content in less than 50ms.

Parallel Workflow: Perfect for developers moving IDs and Emails simultaneously, or translators working with source and target text in two separate slots.

🔐 Privacy:

As a security enthusiast, I designed this with transparency in mind:

In-Memory Only: Clipboard data is stored strictly in RAM and is never written to disk.

Zero Network Access: The app has no network permissions. No telemetry, no analytics, no external communication.

🛠 Tech Stack:

Language: Swift 5.9+ / SwiftUI & AppKit Hybrid

The project is licensed under MIT, and I’d love to get some feedback or contributions from this community!

Thank you for reading my small project!

🔗 GitHub Repository: https://github.com/RAKKUNN/DualClip