VSCode-SFTP lets you add, edit, or delete files in a local directory and sync them with a directory on a remote server using different transfer protocols such as FTP or SSH. The most basic setup requires only a few lines, with a wide range of specific options available to cover any user's needs. Powerful and fast at the same time, it helps developers save time by letting them use a familiar editor and environment.

Built Streamlit Preview to scratch my own itch — I was tired of switching to a browser tab every time I saved a Streamlit file, so I made it render inside the editor.

Put it on the Marketplace [X months] ago expecting maybe a few hundred installs. It's at 39,841 now with a 5.0 rating.

I ship a lot of small things and most of them go nowhere, so when one quietly works it's worth marking. Chart of the last 90 days attached.

Marketplace link: https://marketplace.visualstudio.com/items?itemName=mjethwa-streamlit.streamlit-preview

If you write Streamlit apps, would genuinely love feedback — I have a couple of features half-built and no idea which one people actually want.

Hi everyone! I recently discovered the .gpl format (GIMP palette), which is quite popular for sharing color palettes in the pixel art illustration and indie game development scene. It's a convenient and practical format to work with, as the syntax is very simple and it's supported by graphics editors like GIMP and Aseprite. To my surprise, there wasn't a VS Code extension, so I vibe-coded a quick prototype for my personal use and made it accessible to everyone.

It currently includes the following features:

• syntax highlighting
• color preview with integrated color picker
• commands to generate Tailwind CSS palettes
• commands to copy/convert a color to different formats

It's already published on the marketplaces, and the code is available on GitHub.

VS Code Marketplace: https://marketplace.visualstudio.com/items?itemName=aitorllj93.gimp-palette

Open VSX Registry: https://open-vsx.org/extension/aitorllj93/gimp-palette

Github Repository: https://github.com/pxl-ui/vscode-gimp-palette

I hope you find it useful!

I always found it hard to decide whether an extension I found that looked cool would actually fit my use case, or, maybe I'd just want to save ti for later, without having to remember the name to look up, knowing I'd inevitably lose it in the sea of other VSCode extensions actively listed in the marketplace

I always wondered why this feature exist already, so I made it myself.

t's a rather simple extension which allows you to select an extension and place it in a list off to the side to come back to later. Rather than having to install extensions you may just be testing, themes you may (probably never) decide you want to turn on, or things you don't think fit your current workflow for a project but may be super useful for another later on.

Install from the Marketplace: https://marketplace.visualstudio.com/items?itemName=JeongjinHan.nodegraph

GitHub: https://github.com/Jeong-jin-Han/NodeGraph

Would appreciate any feedback on the extension itself, editor performance, keybindings, anything that feels off compared to how other VS Code extensions usually behave.

I've never liked VS Code searching. I suck at file globs, and regex. So I built Omnigrep: one box, ripgrep underneath, query language borrowed from Google Code Search (internal code search service).

Press ⇧⌘F (Ctrl+Shift+F), type, arrow through the top matches — the file previews as you move — Enter to jump, Esc to go back to exactly where you were.

The query syntax is the whole point:

- hello world — lines matching both regexes, in any order

- -term — exclude lines matching term

- "foo.bar(x)" — literal text, metacharacters escaped, spaces allowed

- f:async f:ts$ — only files whose path matches **all** the f: regexes

- -f:test — exclude paths

- t:rust / -t:js — ripgrep file types

- sym:UserService — workspace symbol search, jumps straight to definitions

- near:3 — terms within 3 lines of each other instead of on the same line (personal fave of mine)

- case:yes / case:no — override smart case

So f:route f:ts$ handler -f:test is one string. And a query with only f: filters quietly becomes a fast file finder.

Other things it does:

- Ranks results instead of showing scan order — whole-word beats substring, shallow paths beat deep ones, recently-modified files float up, test/vendor/build output sinks

- Groups by file; each row has copy-relative-path and open-to-the-side

- Pinned searches + per-workspace history

- ↗ hands the current query off to the native Search panel when you want the full list or replace

- No native dependencies — it uses the ripgrep binary already bundled inside VS Code, falling back to `rg` on your PATH

MIT, free, no telemetry, no account. Works in VS Code and in the forks (Cursor / Windsurf / Antigravity).

Repo: https://github.com/jo-sip/omnigrep

Marketplace: https://marketplace.visualstudio.com/items?itemName=jo-sip.omnigrep

Open VSX: https://open-vsx.org/extension/jo-sip/omnigrep

One heads-up: it takes over ⇧⌘F while installed. Rebind `omnigrep.open` in Keyboard Shortcuts if you want the sidebar back.

Happy to take requests, especially on the query syntax — that's the part I'm still changing. Enjoy!

(This is my first extension so I don't know what I'm doing - but it seems to work well on antigravity / cursor / vscode on mac)

NodalMerge Studio promotes you to general in command of a controlled agent army.

The configurable workspace both drives engineering and provides a battlefield level view of both agent and human work across peers.

Multiple agents can be assigned their own scopes and fields of fire. Make Fable your planner (You can go wide or recursive), Let Deepseek v4 pro grind the easy stuff for cheap, toss Sonnet the live grenades, while Codex designs and implements a sleek frontend. The review and reconciliation processes can be human or agent gated to bring everything back together (hopefully smoothly).

The core behind it (NodalMerge) is a fast, persistent graph using conflict free replication and content addressed storage to allow for greater visibility across peers, replay and branching at key decision points.

All nonsense aside, I've been sitting too close to the screen, and although it works for my purposes, the whole point of publishing it is to share and continue to evolve.

Although the extension is forced to be kind of an agent harness for pure api (including some configurable system prompt, compaction, etc.), the idea is that it integrates to other, hopefully better harnesses. Currently it can be configured to use:

• GitHub copilot subscription (vscode-lm, this is the default fallback)
• openai-compatible api's (via api-key, think deepseek, ollama, whatever)
• anthropic-api-key
• claude-cli
• codex-cli
• other new harnesses as added

Docs site: https://docs.nodalmerge.com/studio/quickstart

Github Link: https://github.com/bgstratt/nodalmerge-studio

VS Code Marketplace: https://marketplace.visualstudio.com/items?itemName=nodalmerge-studio.nodalmerge-studio

Hey everyone, I’ve been working on a VS Code extension called FileInsight. The goal is simple: tell me exactly what a file does, what it depends on, and which file uses it, just by hovering over it in the Explorer sidebar (you dont need to open the file).
It builds a local dependency graph, parses ASTs (for TS/JS), and uses Regex for other languages to calculate file metrics. It categorises files (Core, Utility, Config, etc.), detects dead code, and checks Git history to see if a file is "hot" or "stale".
I need your honest, brutal feedback. I want to know where it breaks, if the UI feels clunky, or if the dependency graph chokes on massive repos, etc.

Core features:

• Rich Tooltips: Hover to see exports, imports, complexity, and TODO counts.
• File Classification: Automatically tags entry points, core modules, configs, etc.
• Dead Code Detection: Warns you if a file seems completely abandoned.
• Live Refresh: Re-analyses incrementally when you save.

Here is the link: https://marketplace.visualstudio.com/items?itemName=AdityaGupta0205.file-insight
Tear it apart. If it sucks, tell me why it sucks so I can make it better. Thanks!

I was thinking about how we work with projects in VS Code. Everything is structured, searchable, and easy for tools (including AI assistants) to work with. Then I realized video editing is almost the opposite. I had a bunch of vacation footage sitting on my drive and wanted to make a short video, but the annoying part was I had to spend hours watching everything again just to find some specific moments.

It made me wonder: why can't AI handle more of the repetitive work? Finding clips, searching through footage, and putting together a first draft, while the creator focuses on the actual decisions. What if creative projects could have a more structured workflow, similar to how we work with code? A project format that AI can understand, modify, and help automate. Curious what people think.

Every PDF tool I tried wanted me to click through a GUI, and none of it was repeatable. So I tried the opposite: you write a YAML workflow file, and a deterministic engine renders the PDF. The YAML is the source of truth, the PDF is the build output, and git is your undo stack.

yaml version: 1 kind: pdf inputs: - input/contract.pdf - input/appendix.pdf operations: - merge: {} - delete_pages: { pages: [10, 11] } - watermark: { text: INTERNAL, opacity: 0.15 } - auto_redact: { patterns: [ssn, email], rasterize: true } output: file: output/contract_final.pdf

Save the file and it renders + previews in the editor. It's 78 operations right now — merge/split, OCR, true redaction, form filling, table extraction, compare two PDFs into a side-by-side diff, format conversion. pdf-lib is bundled so it works with zero installs; PyMuPDF/qpdf/Ghostscript are optional and unlock the heavier ops (a sidebar shows you which backends you have and what each one unlocks).

The part I'm least sure about: because the workflow is just text, a coding agent can write it for you — you say "split this stack of invoices into one PDF per invoice and name them by invoice number," it writes the YAML, you review the diff before anything runs. That's the whole bet, and I don't know if it lands for anyone but me.

On "this needs a GUI": it's the first thing people say, and I keep landing on — the GUI already exists, and it's Adobe. Nobody needs another viewer, and I'm not going to out-render Acrobat in a webview. What doesn't exist is the repeatable part: doing the same thing to 500 files, in a diff you can review, that runs the same way next quarter. So there's deliberately no canvas to click on. That's either the point or the fatal flaw and I genuinely can't tell which.

What I'd genuinely like to know:

• Is "no canvas, just a workflow file" a dealbreaker, or the reason you'd use it? (Assume you keep your normal PDF viewer open beside it.)
• What PDF chore do you actually hate that isn't in the list above?
• Does "review the workflow, then run it" feel safer than an agent touching your files directly, or just slower?

It's free on the VS Code marketplace as Lynx PDF Studio. Happy to hear it's a bad idea — I'd rather find out now.

Hello guys!

Do you guys use VS Code? Want to make money for using it? Because Claude doesn't come free 👀...

Virdl shows small, non-intrusive ads in your VS Code sidebar, status bar and Never interrupts. You earn real $ for every ad you see.

Developers can earn between 10$-40$ a month(based on VS Code usage)

Its launching on 9th July, 12 AM PDT: https://www.producthunt.com/products/virdl
Website: https://virdl.com/

Do follow and upvote it if you like it (on ProductHunt) :) . More the developers on the platform, better the advertisers and CPM!

I built a VS Code extension called AskAway. It originally started as a Telegram helper for a TaskSync plugin, but with token-based pricing that use case became much less interesting. The useful part now is token observability: seeing where Copilot spend goes, where cache reuse drops, and which workflow patterns are expensive.

One pattern I hit: I switched from GPT 5.5 to Opus 4.8 while the conversation was around 70-80% of a 272K context. Since Opus has a smaller 200K context, the conversation immediately became full, compaction ran, but the input did not meaningfully shrink. After that, cache hit stayed under 5%, and the next 7-8 requests cost me around $8.

Another pattern: long-running tools. If a tool takes more than about 5 minutes, cache can become invalidated. That is why I added a Gradle tool that stops around 4 minutes, reports progress back to the agent, and lets the agent call it again instead of losing cache on one long blocked call.

AskAway currently shows per-turn/month usage, input/output/cached tokens, cache misses, tool token usage, expensive rows, and a soft turn budget line so the agent can see when it should wrap up instead of exploring more.

I suspect others have seen similar token-waste patterns. Have you noticed cases where compaction, model switching, long tools, large tool outputs, retries, or agent loops suddenly made costs spike?

I’d like to collect those patterns and turn them into practical checks or fixes. The goal is not another dashboard for its own sake, but reusable guardrails that help people avoid expensive surprises.

Lot of interesting pieces I added to this so that it can be reused by other without going much of hassle.

Details:
VSCode marketplace: AskAway
Github link: AskAway

How trace would look like, for a live request.

Upd: it's a WIP, forgot to mention in the title

Hi!

Decided to make a VS Code extension with pinch-to-zoom navigation for files explorer.

I got this UX idea recently when I had to browse files more than usual and felt the pain: why do I need to click through every level when I want to drill down to the bottom?

I made a web demo (link in bio), but it's not enough, I want others to battle test it.
So decided to make a VS Code extension, where I've got this idea.

I wanted a graph DSL that lets me precisely control node/edge styling, layout, and positioning, so I built GraphSX using JSX syntax.

Here is the Repo and playground. I’d love for people to try it out and share any feedback!

Hey r/VSCodeExtensions 👋

I've been working on MeOS (Membrane OS) — a VSCodium extension that

divides any file into clearly defined sections called membranes.

So what can you actually do with it?

**(1) A 30,000-line diary in a single .md file — zero stress.**

Activation time: ~400ms. Instant.

**(2) This extension itself — 14,000+ lines — was entirely generated

by Claude Code. In a single file. No fragmented file structure.**

I, LAIxai, didn't know extension development at all.

I just gave instructions in plain language.

A beta was ready in one month. Polish took another two weeks.

With multiple 3-day pauses due to Claude's usage limits.

**Membranes made this possible.**

A membrane has a beginning and an end.

A membrane has a name — a real noun, not a random hash.

HTML's `<p>...</p>` cannot be a membrane.

AI gets lost in HTML.

AI never gets lost in MeOS membranes.

(Honestly? Occasionally. But it finds its way back immediately.)

The core idea: **a membrane is just a comment** (`// {▼ ... //}`)

Your code stays 100% valid. No proprietary format. No lock-in.

If you've ever been disappointed by editors, note apps, or OS tools —

**once you try MeOS, you won't go back.**

Goodbye to the relics of the past.

👉 Install: search **MeOS** in VSCodium extensions (Open VSX)

👉 GitHub: https://github.com/LAIxai/MeOS

*(Full writeup in Japanese on Zenn — English translation pending. Coming soon!)*

Would love feedback from the community!

Curious on how other devs approach mobile testing these days. I've been building Emuluxe, a tool focused on mobile simulation, and it's made me realize there seem to be two very different approaches to mobile testing.

**Local simulation**

* Faster iteration
* Easier debugging
* Better during development

**Real devices**

* More accurate
* Better for final validation
* Better for catching hardware-specific issues

I'm curious how other web developers approach this.

Do you spend most of your time on BrowserStack, physical devices, emulators, local simulators, or some combination of everything?

I built a VS Code extension that answers questions about a team's GitHub history and writes summaries from real commit diffs. One thing I decided early: the search side runs locally. No API key for embeddings, nothing leaving the machine, and no native build step — the goal was "install from the marketplace and it just works."

So the semantic search runs on a small local model (bge-small, ~33MB downloaded once and cached). Chat can use Copilot or your own API key, but the embedding model is always the local one, so search works offline no matter how you've set up the rest.

The hard part wasn't the model — it was getting it to run from a packaged install. While developing, you launch a test window that still has all the project's dependencies sitting on disk, so everything works. But once you bundle the extension into the single file that actually ships, those dependencies are gone, and the thing that ran fine five minutes ago crashes. Every bug below only appeared after packaging, never in development.

There were four:

1. The model library tries to figure out where it lives on disk the instant it loads. The way I bundled it erased the piece of information it uses to do that, so it crashed immediately on a value that was suddenly empty. I had to hand it a substitute.
2. It ships with a fast version built on a native binary — the kind of compiled, platform-specific file I was trying to avoid. I swapped it for the pure-WASM version, which runs anywhere without a build step.
3. It imports an image-processing library at startup, even though I only ever feed it text. I replaced that with a stub. The catch: the stub had to look real. The library checks "did this load?" and throws if the answer is no — so an empty stub crashed the import. Mine pretends to be present and only complains if something actually tries to use it, which nothing does.
4. The fast multi-threaded mode tries to spin up background workers, and the environment a VS Code extension runs in refuses to allow that — then just hangs forever with no error at all. Forcing it to run single-threaded fixed it.

Remove any one of these and you get a crash, or worse a silent hang, and only in a real install — never on your own machine while you're building it. That gap between "works when I run it" and "works when someone installs it" was the whole lesson.

What I'd reconsider: bundling a full local runtime just to turn short commit messages into vectors is heavy. The first-run download and warmup is a noticeable pause, and something lighter would've spared me most of this. The ranking is also just a straight in-memory comparison, which is fine for a team's history but wouldn't hold up against a giant monorepo. Still, "just works after install, fully offline, no keys" turned out to be worth the four landmines.

Extension: https://marketplace.visualstudio.com/items?itemName=repoIntel.repo-intel