claude-code - 💡(How to fix) Fix [BUG] Postgres network egress blocked even with full network permissions

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

psycopg2.OperationalError: connection to server at "XXXXXXX", port 6543 failed: Connection timed out Is the server running on that host and accepting TCP/IP connections?

Code Example

psycopg2.OperationalError: connection to server at "XXXXXXX", port 6543 failed: Connection timed out
        Is the server running on that host and accepting TCP/IP connections?
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

Postgres outbound is blocked from the cloud sandbox. aws-0-us-east-1.pooler.supabase.com:5432/6543 time out. Even with a full permission network policy.

I imagine this issue isn't just limited to Postgres, but probably all non-HTTP/s ports? I have not tested this.

If this is an intentional behavior, it should be documented. I was unable to find documentation about this behavior.

What Should Happen?

Connection to remote Postgres server should be allowed in full permission mode. Another option is in the allowed policies giving users the ability to enable host and port.

Error Messages/Logs

psycopg2.OperationalError: connection to server at "XXXXXXX", port 6543 failed: Connection timed out
        Is the server running on that host and accepting TCP/IP connections?

Steps to Reproduce

Steps to reproduce

  1. Start a Claude Code on the web session against any repo (cloud sandbox).
  2. From a shell, try a raw TCP connect to a Supabase pooler endpoint: bash -c 'echo > /dev/tcp/aws-0-us-east-1.pooler.supabase.com/5432'; echo "exit=$?" bash -c 'echo > /dev/tcp/aws-0-us-east-1.pooler.supabase.com/6543'; echo "exit=$?"

(You can substitute any Supabase project's direct host, e.g. db.<project>.supabase.co:5432, or a bare IP.) 3. Also try via Python: python -c "import socket; socket.create_connection(('aws-0-us-east-1.pooler.supabase.com', 5432), timeout=10)"

Expected

TCP connection succeeds (exit=0 from the bash test; no exception from Python). The session can then open a psycopg2 / asyncpg connection to its Supabase database.

Actual

Both attempts hang and then time out:

  • bash test exits with 124 (timeout) after ~2 min.
  • Python raises socket.timeout / ConnectionTimeoutError.
  • psycopg2.connect(...) raises: psycopg2.OperationalError: connection to server at "<host>", port <port> failed: Connection timed out

DNS resolution works (getent hosts <host> returns an address); only outbound TCP to the Supabase hosts is being dropped. Other outbound TCP (e.g. github.com:443) succeeds, suggesting it's a per-destination policy rather than a full egress block.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

cloud

Platform

Anthropic API

Operating System

Other

Terminal/Shell

Other

Additional Information

No response

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Postgres network egress blocked even with full network permissions