[Feature] allow web_fetch tool to use proxy

[JokerQyou]

🎯 The Goal / Use Case

Some environment requires proxy to access the Internet. web_fetch should honor HTTP_PROXY or other proxy configuration so the agent can properly browse the web.

💡 Proposed Solution

Let web_fetch tool honor HTTP_PROXY environment variable, or add tool config sections for that.

🛠 Potential Implementation (Optional)

None.

🚦 Impact & Roadmap Alignment

• This is a Core Feature
• This is a Nice-to-Have / Enhancement
• This aligns with the current Roadmap

🔄 Alternatives Considered

I asked the agent to fetch an reorganize picoclaw changelogs for me, but GitHub release note URL is not accessible without network proxy. So I installed GitHub cli skill and asked the agent to use gh api command to query GitHub API, but that did not work either, because commands not installed in workspace directory are always blocked (error is Command blocked by safety guard (path outside working dir)).

💬 Additional Context

See above.

[nikolasdehor]

For context: I reviewed PR #422 (by mattn) which claims to fix this, but it actually doesn't address the real problem.

The change in #422 adds Transport: http.DefaultTransport to the Brave search provider's HTTP client. However, when Transport is nil on http.Client, Go already uses http.DefaultTransport (which includes Proxy: http.ProxyFromEnvironment). So the search providers already respect proxy settings — the change is a no-op.

The actual problem is in WebFetchTool.Execute() (~line 416 of pkg/tools/web.go), which constructs a custom http.Transport{} without setting the Proxy field:

```go
Transport: &http.Transport{
MaxIdleConns: 10,
IdleConnTimeout: 30 * time.Second,
DisableCompression: false,
TLSHandshakeTimeout: 15 * time.Second,
},
```

When you manually construct an http.Transport{}, the Proxy field defaults to nil (no proxy), unlike http.DefaultTransport which sets Proxy: http.ProxyFromEnvironment.

The fix is simply adding Proxy: http.ProxyFromEnvironment to this custom transport. I've pointed this out on PR #422.

[anpic]

maybe should provide support so that we can use our own http.Client or http.Transport?
in addition to supporting environment variables
as example

import "github.com/imroc/req/v3"

transport := &http.Transport{ ... }
httpClient := req.C().SetTransport(transport)

or

import "github.com/ybbus/jsonrpc"

proxyURL, _ := url.Parse("http://proxy:8080")
transport := &http.Transport{Proxy: http.ProxyURL(proxyURL)}
httpClient := &http.Client{Transport: transport,}
rpcClient := jsonrpc.NewClientWithOpts("http://my-rpc-service:8080/rpc", &jsonrpc.RPCClientOpts{
	HTTPClient: httpClient,
})

after all, picoclaw can be used as a library 😉

[nikolasdehor]

@anpic Agreed — exposing a hook for custom http.Transport would be the cleanest long-term solution. Something like:

type WebFetchConfig struct {
    Transport http.RoundTripper // nil = default with ProxyFromEnvironment
    Timeout   time.Duration
}

For now, PR #447 adds http.ProxyFromEnvironment to the existing transport, which covers the most common case (env-var-based proxies). A follow-up could add the full Transport override for users who need custom TLS configs, client certs, etc.

[sipeed-bot]

@JokerQyou Hi! This issue has had no activity for over 2 weeks, so I'm closing it for now to keep things tidy. If it's still relevant, feel free to reopen it anytime and we'll pick it back up.

[JokerQyou]

But this is not done, is it? I don't see any referenced PR gets merged. If it's not done then you don't close it as completed, because it is not completed.

[anpic]

@JokerQyou

This issue has had no activity for over 2 weeks, so I'm closing it for now to keep things tidy.

stupid bots 😃 just reopen the issue 😉

[anpic]

@nikolasdehor can this bot logic be changed?