Nextcloud PHP debugging with Xdebug in Zed editor

I started to switch from PhpStorm to Zed as IDE recently as Zed is open source and has a much smaller footprint and is more slick than PhpStorm.

One thing that I didn't get running immediately was Xdebug integration, so I did a bit of research and asked Claude for help. Here's a quick writeup of how to get it running.

I have Zed installed as Flatpak on a Debian Trixie host system.

The PHP process runs in a nextcloud-docker-dev Docker container.

Install Zed and configure debugging there

Install Zed: flatpak install flathub dev.zed.Zed

In Zed: open the Extensions view and install PHP.

Configure the debugger:

Create ~/.var/app/dev.zed.Zed/config/zed/debug.json:

[
  {
    "label": "PHP: Listen to Xdebug",
    "adapter": "Xdebug",
    "request": "launch",
    "port": 9003,
    "pathMappings": {
      "/var/www/html":             "/home/<user>/devel/nextcloud/server",
      "/var/www/html/apps-extra":  "/home/<user>/devel/nextcloud/server/apps-extra",
      "/var/www/html/apps-shared": "/home/<user>/devel/nextcloud/apps-shared"
    }
  }
]

Add one entry per bind-mounted app directory.

After creating the file, restart Zed.

Inside Zed, select "debugger: start" from command palette and then "PHP: Listen to Xdebug".

Verify Zed is listening. Running ss -tlnp | grep 9003 on the host should show *:9003 with Zed as the process.

Configure Xdebug inside the container

/usr/local/etc/php/conf.d/xdebug.ini:

xdebug.mode = debug
xdebug.idekey = PHPSTORM
xdebug.trace_output_name=trace.%R.%u
xdebug.profiler_output_name=profile.%R.%u
xdebug.output_dir=/shared/xdebug

xdebug.log = /var/log/xdebug.log
xdebug.log_level = 3

; Try to discover the client host, otherwise fall back to the docker host
xdebug.discover_client_host=true
xdebug.client_host=host.docker.internal

; When you cannot specify a trigger, use "xdebug.start_with_request = yes" to autostart debugging for all requests
; https://xdebug.org/docs/all_settings#start_with_request
xdebug.start_with_request = trigger

; Set xdebug.mode trace to use this
; More details at https://derickrethans.nl/flamboyant-flamegraphs.html
xdebug.trace_format=3
xdebug.trace_output_name=xdebug.%R.%u

Apply changes by restarting apache in the container: apache2ctl -k graceful

Notes:

• host.docker.internal resolves on Linux Docker only if the container was started with --add-host=host.docker.internal:host-gateway (nextcloud-docker-dev already does this).
• discover_client_host = true makes xdebug follow X-Forwarded-For - useful behind Nextcloud's dev reverse proxy.

Test xdebug with a PHP command inside the container

Run XDEBUG_SESSION=PHPSTORM php occ status inside the container and check /var/log/xdebug.log.

Install the browser extension

Install Xdebug Helper (Firefox/Chrome). In its preferences, set the IDE Key to PhpStorm. It will set the XDEBUG_SESSION cookie when toggled to Debug.

Click the Xdebug Helper icon in the browser and set it to Debug.

Test Xdebug with browser extension

Load the URL that exercises the code path with the breakpoint. Zed should stop the code exection at the breakpoint.

14 Jul 2026 10:46am GMT

Introduction

Recently, I've got a chance to try building Mozc (Most famous Japanese input method editor) with Bazel.

As you know, recently newer Bazel related packages were landed into debian/unstable. Then now I'm planning to update Mozc from 2.29.5160.102 to 3.33.6133.

Background story about Mozc and Debian

The upstream of Mozc had released 3.34.6239, but on Debian, we stick to Mozc 2.29.5160.102.

Mozc requires newer Bazel but we only had Bazel 4.2.3 at that time on Debian, so even though the upstream of Mozc switched from GYP to Bazel, we had patched Mozc with GYP based package.

We even did make an effort to restore build options that had been already removed. :-( And needed to migrate from GTK2 renderer to GTK3 renderer.

That is why the version of Mozc is diverged from upstream on Debian.

• 2.29.5160.102 (Now on Debian)
• 2.29.5268.102
• 2.29.5374.102
• 2.29.5544.102
• 2.30.5544.102
• 2.31.5712.102
• 2.31.5851.102
• 2.32.5994.102
• 3.33.6089
• 3.33.6133 (Target to upgrade for)
• 3.34.6239

How to switch from GYP to Bazel?

At first, we needed to decide what Mozc version to work with it.

Now latest version of Mozc is 3.34.x, but it requires Bazel 9.x. Please recall that Bazel 7.7.1 was introduced Debian/unstable. And more, newer dependency libraries are required.

You might feel that target version (3.33.6133) is too high from 2.29.5160.102, but if we upgrade to more older Mozc, it means that it requires to backport Mozc to older libabsl compatible codes and so on.

That is why Mozc 3.33.6133 was chosen.

Even once the target version has been decided, you can't let your guard down.

There are many technical tasks to solve.

• Revisit patch sets to apply
• Porting uim mozc patch and fix FTBFS
• Porting fcitx5 mozc patch and fix FTBFS
• Fix src/third_party vendoring
• Switch from GYP to Bazel build systems
• ...

At least, it will likely require several rounds of testing in the Debian experimental.

Conclusion

Currently, gbp buildpackge has succeeded finally on local machine, but need to tidy and cleanup stuffs.

I didn't know packaging with Bazel best practice yet, to remove many third party vendor/ bundles, I've found that it requires pile of patch to eliminate them.

In the current version of Debian, as a one of build system, further work - such as support from debhelper - will be needed.

I'll file working progress on #1085173

12 Jul 2026 2:10pm GMT

Following up on my previous post, I am releasing debvulns-exporter, a Prometheus exporter for tracking Debian system vulnerabilities. The underlying vulnerability analysis logic remains identical to the previously released MCP server and CLI utility.

12 Jul 2026 11:30am GMT