If you're trying to use another Sway session inside your own Sway session (either a nested Sway session or a remote Sway session) or you use an application that uses the same shortcuts as Sway, then you'd like Sway to "get out of the way" and let those shortcuts through.
You can do that by defining a passthrough mode in ~/.config/sway/config:
# Passthrough mode
mode "passthru" {
bindsym $mod+Escape mode "default"
}
bindsym $mod+Escape mode "passthru"
When you hit Mod+Escape, it enters the "passthru" mode, in which the same binding, Mod+Escape, is the only binding that does anything at all - and that is returning to normal mode. All other normal bindings in that mode will be ignored by Sway and will reach either your nested / remote Sway desktop or your application that expects them.
Here's an example of Sway / application conflict:
In my Sway, Ctrl+Shift+e is set to brings up the emoji picker (rofimoji if you're curious). But Ctrl+Shift+e is also the shortcut to bring up the Developer Tools pane in Firefox. So when I infrequently need the latter, I enable the passthrough mode first.
Of course, when you enter the passthrough mode, passthru appears in your (s)waybar. You'd think it makes it obvious that you're in a special mode, but it's actually really easy to enter the passthrough mode and forget about it. Therefore, if no bindings seem to work properly anymore, remember to look down ๐
Also, if you ever need to enter the passthrough mode in a nested / remote Sway session - like for example if you need the Firefox Developer Tools pane in a remote Sway session, then you'll have to define a different binding to switch passthrough on and off, either in the local session or in the remote session, otherwise they're going to clash.
But it happens very rarely for me, so I didn't bother: all my machines use the same passthrough mode binding in i3 and Sway and I've never run into the problem. But it can happen.