When setting up Sway as your Wayland compositor, you might want to organize your Waybar configuration in a non-standard location — for example, keeping a dedicated ~/.config/waybar/sway/ directory to separate your Sway-specific bar configuration from others.

This seemingly simple task comes with a couple of subtle pitfalls worth knowing about.

The ~ Expansion Problem

The most natural approach would be to launch Waybar directly from the bar block in your Sway config:

Unfortunately, this does not work. The swaybar_command directive does not perform shell expansions, so ~ is passed literally to the command instead of being expanded to your home directory. Waybar will fail to find the configuration file.

A workaround is to launch Waybar via exec instead:

However, this approach has its own drawback: Waybar launched via exec is no longer managed by Sway’s bar subsystem. This means that Sway bar commands — such as swaymsg bar hidden_state toggle to show/hide the bar — will not work.

The Solution: A Wrapper Script

The cleanest solution is to write a small wrapper script that handles the expansion and launches Waybar with the desired configuration:

Make it executable:

Then reference it in your Sway config:

Now Waybar is properly managed by Sway’s bar subsystem, and the script handles path expansion.

The PATH Problem

There is one more subtle issue: the script lives in ~/.local/bin/, which may not be in PATH when Sway starts. Sway is typically launched from a display manager or TTY, where the environment is minimal and does not source your shell’s configuration files (e.g., ~/.bashrc or ~/.zshrc).

To ensure ~/.local/bin is in PATH for Sway and all processes it spawns, add it in your login shell profile:

Your display manager or TTY login will source this file, making the script discoverable when Sway starts.