What causes "URL reads are disabled by settings." in can1357/oh-my-pi?

Enable the setting: set "fetch.enabled": true in your opencode/coding-agent settings and retry.

can1357/oh-my-pi · warning · ToolError

URL reads are disabled by settings.

Error message

URL reads are disabled by settings.

What it means

The fetch tool refuses to read a URL when the `fetch.enabled` setting is false in the session settings. materializeReadUrlToFile checks this gate before calling fetchReadUrl, so any URL read attempt hits this guard when fetch is turned off. It is a deliberate configuration kill-switch, not a network failure.

Source

Thrown at packages/coding-agent/src/tools/fetch.ts:1692

			contentType: result.contentType,
			method: result.method,
			truncated: Boolean(result.truncated),
			notes: result.notes,
		},
		image: result.image,
		output,
		content: result.content,
	};
}

/** Materialize rendered URL body text to a local file for tools that require filesystem paths. */
export async function materializeReadUrlToFile(
	session: ToolSession,
	params: { path: string; raw?: boolean },
	signal?: AbortSignal,
): Promise<{ path: string; details: ReadUrlToolDetails }> {
	if (!session.settings.get("fetch.enabled")) {
		throw new ToolError("URL reads are disabled by settings.");
	}
	const entry = await fetchReadUrl(session, params, signal);
	const contentPath = await materializeReadUrlContent(session, entry, params.raw ?? false);
	return { path: contentPath, details: entry.details };
}

function buildUrlReadOutput(result: FetchRenderResult, content: string): string {
	let output = "";
	output += `URL: ${result.finalUrl}\n`;
	output += `Content-Type: ${result.contentType}\n`;
	output += `Method: ${result.method}\n`;
	if (result.notes.length > 0) {
		output += `Notes: ${result.notes.join("; ")}\n`;
	}
	output += `\n---\n\n`;
	output += content;
	return output;
}

View on GitHub (pinned to 9690622007)

Solutions

Enable the setting: set "fetch.enabled": true in your opencode/coding-agent settings and retry.
If fetch should stay off, handle the ToolError and tell the user/prompt that URL reads are unavailable, or supply content another way (paste the page, use a local file).
Verify which settings scope (project vs global) is disabling fetch; remove the restrictive key if unintended.

Example fix

// before (session with fetch disabled)
await materializeReadUrlToFile(session, { path: "https://example.com" });
// after: enable in settings.json
{ "fetch": { "enabled": true } }

Defensive patterns

Strategy: validation

Validate before calling

if (!session.settings.get("fetch.enabled")) {
  // surface a friendly message or skip the URL step
  return null;
}
return materializeReadUrlToFile(session, params, signal);

Try / catch

try {
  const { path, details } = await materializeReadUrlToFile(session, params, signal);
} catch (err) {
  if (err instanceof ToolError && err.message.includes("URL reads are disabled")) {
    // fall back to a local source or inform the user
  } else throw err;
}

Prevention

Check session.settings.get("fetch.enabled") before invoking any URL-reading tool.
Document in your project config that fetch.enabled gates web access.
Provide non-network fallbacks (local files, pasted content) in environments with fetch disabled.

When it happens

Trigger: Calling materializeReadUrlToFile (or the read-url tool it backs) while session.settings.get("fetch.enabled") is falsy — e.g. fetch disabled in project or global settings.

Common situations: Users with fetch disabled for security/compliance reasons; a prompt asks the agent to fetch a web page but config never enabled the fetch tool; settings file typo sets fetch.enabled to false or omits it with a default-off policy.

Related errors

AI-assisted analysis of can1357/oh-my-pi@9690622007 (2026-08-31). Data as JSON: /api/errors/86f62b9727bf47ab. Report an issue: GitHub.