Skip to content

follow-up: sweep ~20 community extensions to use ${BIND_ADDRESS:-127.0.0.1} pattern #504

@yasinBursali

Description

@yasinBursali

Context

Surfaced during CG review of PR 1.4 (jupyter exec-form command, fix/jupyter-exec-form-command).

The dreamserver-context skill's claim that PR Light-Heart-Labs#1027 swept 29 community extensions to the ${BIND_ADDRESS:-127.0.0.1}:<host>:<container> pattern (per PR Light-Heart-Labs#964) does not match the current state of upstream/main. Spot-check from CG agent during 2026-04-26 review found ~20 community extensions still using bare 127.0.0.1: port bindings:

anythingllm, bark, audiocraft, chromadb, baserow, continue, forge, crewai, flowise, frigate (×4), invokeai, gitea (×2), immich, label-studio, langflow, jupyter

Why this matters

BIND_ADDRESS=0.0.0.0 (set when operator opts into LAN mode via --lan or dashboard toggle) does not propagate to these extensions because they hardcode loopback. Net effect: LAN mode is partially broken for these extensions — they remain loopback-only when the rest of the stack opens up.

Proposed scope

Sweep resources/dev/extensions-library/services/*/compose.yaml to apply the ${BIND_ADDRESS:-127.0.0.1}:<host>:<container> pattern uniformly. Add a regression test (analogous to existing tests/test-bind-address-sweep.sh for the built-in extensions) to prevent future drift in the community library.

Severity

Medium — partial LAN-mode breakage for any user enabling these community extensions in LAN mode.

Source

CG review of PR 1.4 fix/jupyter-exec-form-command, batch 1 (2026-04-26).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions