v0.5.6 registered operator fonts by dropping a snippet in
$XDG_CONFIG_HOME/fontconfig/conf.d. On a host install that is right. In the
container it is not: the launcher points XDG_CONFIG_HOME at the config VOLUME
ROOT, which an unprivileged process cannot create a directory in, so the first
restart after shipping it said

    [fonts] could not register ['/home/ubuntu/.coderai/fonts']:
            [Errno 13] Permission denied: '/config/fontconfig'

and captions kept using the substitute. Two faults, not one: that path is not
writable, and it is also inside the container's own filesystem, which a --rm
container discards at every restart -- so even where it worked it had to be
rewritten on each boot and could never be relied upon.

The snippet is still tried first, because fontconfig reads it unprompted and
so it survives into a grandchild. When it cannot be written, coderai now
writes its own fonts.conf into the config dir one level down -- writable, and
bind-mounted, so it persists -- and exports FONTCONFIG_FILE, which every child
this process starts inherits. That file <include>s /etc/fonts/fonts.conf, so
replacing the main configuration costs nothing: the system families still
resolve.

Verified in the container under the real environment, with the check that
actually matters -- fc-match in a CHILD process, which is the lookup
ffmpeg/libass performs:

    child fc-match 'Montserrat:style=Bold'  ->  Montserrat
    fc-match 'DejaVu Sans'                  ->  DejaVu Sans   (44 faces)

The bug got through because it was verified with `docker exec`, which inherits
a different environment than the supervised server process. A font this
process can find is not necessarily a font the renderer can use, and an exec
is not the deployment.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S8LAP3ueNzQJtwzhgVbq66