# Frida Workbench for VSCode: a mobile reverse engineering workbench in the editor

> vscode-frida is an unofficial VSCode extension that turns the editor into a Frida workbench, with process lists, runtime class and module browsers, hook generation, a language server for Frida scripts and device tooling for Android and iOS. It saves a lot of context switching, and it depends on frida-tools being installed and configured correctly outside the editor.

**ChiChou/vscode-frida** — Unofficial frida extension for VSCode

- Repository: https://github.com/ChiChou/vscode-frida
- Website: https://marketplace.visualstudio.com/items?itemName=CodeColorist.vscode-frida
- Stars: 591 · Forks: 55
- Language: TypeScript
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/chichou-vscode-frida

## The extension drives frida-tools, it does not replace it

Frida Workbench for VSCode is an open source extension for Visual Studio Code that aims to enhance the Frida scripting experience, and the first thing the README says about its own status is that it is a community contributed project not affiliated with the official Frida team, developed and maintained by CodeColorist.

The architecture follows from that. The extension is a front end over the frida-tools command line, so frida-tools has to exist on your machine before anything works. The prerequisites are Python 3.7 or newer and the frida-tools Python package, and the extension activates on startup finished.

The installation note is more than a formality. Because of PEP 668, you might hit an error running pip3 install frida-tools globally. The recommended way is to open a folder in VSCode, create and activate a virtual environment using the Python extension, and in that case the extension uses your currently active Python virtual environment to load the frida commands. The alternative is a package manager such as pipx or UV that installs the tool to your PATH while keeping it isolated.

There are optional dependencies too. libimobiledevice is needed for the inetcat command that starts an SSH shell, and on Windows you need iTunes installed for the iOS USB connection. The README is explicit that on Windows iTunes must be kept open to interact with iOS devices over USB, which is the kind of detail that turns a smooth demo into a debugging session.

## The process list is the entry point to everything else

The apps and processes list is the feature everything else hangs off. It lists apps and processes on connected devices in a sidebar panel, and the right-click menu is where the work starts: attach, attach with higher privileges for local targets, spawn, spawn in suspended mode, kill processes, or copy the device and process info to the clipboard.

The device coverage is broad. It supports local, Apple Simulator, USB and remote devices, and local process entries include best-effort metadata such as the executable path, the owner, the parent PID and the arguments when those are available. Remote devices can be connected through a host:port value directly from the sidebar.

Two of those menu items deserve more attention than they get. Spawning in suspended mode is how you attach to a process before it runs its own code, which is the difference between catching an initialization routine and missing it. Attaching with higher privileges is what you need for a local process owned by another user, and it is a separate menu entry because it is a separate privilege, not a flag on the ordinary attach.

The metadata is described as best-effort, which is the right way to put it. Some of those fields are simply not obtainable on every platform or for every process, and an extension that claimed otherwise would be lying to you.

## Runtime browsers and generated headers replace a lot of manual digging

Once a process is attached, the extension gives you two browsers over the live runtime, and both of them exist to save you from writing the same discovery code by hand.

The Modules and Exports Browser shows the loaded native modules and their exported functions. You can filter modules by name, inspect the base address, the size and the path, and then select exports for hook generation.

The Classes and Methods Browser covers both Java and Objective-C. It filters classes, toggles between own and inherited methods, and lets you batch-select methods for hook generation. It also includes Objective-C protocol inspection, so you can browse and analyse protocols as well as classes.

Then there is Generate Header, which dumps class headers for reverse engineering. For Objective-C it generates header files from the runtime class metadata, and for Java it generates decompiled class stubs with package and import statements.

The practical value of the header generation is that it turns a runtime object into something you can search, diff and paste into your notes. The alternative is to dump the class list and start reconstructing it by hand, which is the tedious part of working on a Java or Objective-C target.

## Hook generation writes the four kinds of hook you actually need

The hook generation feature takes its input from the Modules and Classes panels, and it covers four cases.

Native hooks are generated with Interceptor.attach() and onEnter and onLeave callbacks for exported functions. Objective-C hooks are class and selector based, with the Objective-C bridge used properly. Java hooks use Java.perform() and Java.use() with method overload support, which matters because a Java method with overloads needs the right signature chosen. And there are AI-powered hooks, where GitHub Copilot is used to infer native function signatures, meaning the parameter types and return types, and to generate type-aware argument logging.

That last one is the feature to approach with care, and not because of the usual objection to generated code. A native function signature inferred from a call site is a guess, and the hook it produces is only as good as the guess. It saves you the initial guess, which is useful, but you still have to confirm the argument types before you trust the logging output.

The other three are mechanical, and the value is in the mechanical part. Writing a correct Objective-C hook means knowing the bridge conventions, and writing a correct Java hook means handling overload resolution. Having the editor emit the boilerplate means you spend your attention on the part you are actually investigating.

## The language server needs a target, and the target lives in a workspace file

The extension ships a language server that gives context-aware completions for Frida scripts written in JavaScript or TypeScript, and this is the feature with a real prerequisite attached to it.

The completions are specific: ObjC.classes.<ClassName> completes Objective-C class names, ObjC.classes.Foo['<method>'] completes method selectors, ObjC.classes.Foo.method completes class method selectors, Java.use('<ClassName>') completes Java class names, and Process.getModuleByName('<name>') completes loaded module names.

The catch is that the language server depends on a target process context. You need a configuration file .vscode/frida.json in your workspace, and the easiest way to create it is to right-click a process or app in the sidebar and select Set LSP Target, which generates the file automatically.

The file requires a device field and exactly one of app, pid or process. Attaching by app identifier is the recommended form, and it spawns or attaches to the app:

```json
{
    "device": "local",
    "app": "com.example.myapp"
}
```

Attaching by process name uses the process field instead, and attaching by PID is useful when several processes share the same name:

```json
{
    "device": "local",
    "pid": 1234
}
```

The device value is the Frida device ID: local for the host machine, a Simulator or USB device ID, or a host:port string for remote devices. The language server watches the file for changes, and editing or recreating it automatically restarts the server with the new target, so switching targets does not mean restarting the editor.

## Scaffolding, device tools and the parts that are not about hooking

The rest of the extension is tooling around the hooking, and some of it is where the day to day time goes.

Project scaffolding offers three templates: New Agent, which creates a new Frida Agent project with TypeScript support, New C Module, which creates a new Frida C Module project, and Download Typings, which pulls the Frida TypeScript type definitions for autocomplete. A debug configuration generator produces VSCode launch.json and tasks.json for debugging Frida scripts with breakpoints, which turns the scripts into something you can step through rather than only observe.

For Android, the extension can download and start frida-server on the device, with automatic architecture detection, and it can pull an APK from the device by right-clicking an Android app. The Android server path is configurable, and the default in the package manifest is /data/local/tmp/frida-server.

There is a syslog panel that streams real-time application logs from attached processes, and a shell feature. Open Shell is a wrapper for adb shell on Android, and for iOS it gives an SSH shell on jailbroken devices, which may need credentials configured.

The extension also integrates with Objection for runtime mobile exploration, listed under external tools integration.

The maintenance picture is healthy. The repository is not archived, the last push was on 2026-09-29, and releases are frequent: v0.12.11 on 2026-09-29, v0.12.10 on 2026-06-29 and v0.12.9 on 2026-03-28. The manifest requires VSCode 1.94.0 or newer, and the project is MIT licensed.

## Conclusion

Adopt vscode-frida if you already write Frida scripts and want the target process, its runtime classes and the generated hook code in one window, especially if you work on both Android and iOS and want the same workflow on each. Do not adopt it as a Frida replacement, because it drives the frida-tools command line and needs it installed in a Python environment the editor can see. Before you install the extension, set up a virtual environment with the Python extension and install frida-tools there, since a global pip3 install is blocked by PEP 668, and on Windows keep iTunes open if you plan to reach an iOS device over USB.

## FAQ

### What does the vscode-frida extension do?

It is an unofficial VSCode extension for Frida that lists apps and processes on connected devices, browses loaded modules, exports, runtime classes and methods, generates hook code, streams syslog, scaffolds new projects and includes Android and iOS device tooling. It is a community contributed project, not affiliated with the official Frida team.

### How do I install frida-tools for the vscode-frida extension?

You need Python 3.7 or newer and the frida-tools package. Because of PEP 668 a global pip3 install may fail, so the recommended approach is a virtual environment created with the Python extension in the folder you open in VSCode, and the extension then uses that active environment. pipx or UV are offered as isolated alternatives.

### What does the .vscode/frida.json file configure?

It tells the extension's language server which device and target to attach to. It requires a device field and exactly one of app, pid or process, and the right-click Set LSP Target action in the sidebar generates the file for you. The server watches the file and restarts when it changes.

### Does vscode-frida support iOS and Android devices?

Yes. It supports local, Apple Simulator, USB and remote devices, with an Open Shell wrapper for adb shell on Android and an SSH shell on jailbroken iOS devices. libimobiledevice is an optional dependency for inetcat, and on Windows you need iTunes open to reach iOS devices over USB.

## Sources

- [ChiChou/vscode-frida on GitHub](https://github.com/ChiChou/vscode-frida)
- [License: MIT](https://github.com/ChiChou/vscode-frida/blob/main/LICENSE)
- [Project website](https://marketplace.visualstudio.com/items?itemName=CodeColorist.vscode-frida)
- [README](https://github.com/ChiChou/vscode-frida/blob/main/README.md)
- [Releases](https://github.com/ChiChou/vscode-frida/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chichou-vscode-frida