Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

event add fails with --link; succeeds without it (HTTP 403 observed)

Open
  • Is something wrong?
#555 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
18/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Active
Tech stack
go
Domain
cli

Research direction

Start with the --link flag in internal/cmd/events.go, then check how it maps to calendar_event[url] in go/pkg/hey/calendar_events.go in hey-sdk. Reproduce with a public HTTPS URL to see whether the 403 depends on the link value, and compare the request with a no-link run. Done means the link is accepted or the CLI returns a clear validation error, with the cause recorded.

Written by the indexing model from the issue text.

Description

A timed event with --link failed through the CLI, while the same reference URL was saved successfully through HEY's normal browser event form.

Observed results
  • In a cloud Linux environment, HEY CLI 1.7.0 (SDK 0.31.1, OAuth) returns Form request failed (HTTP 403) from POST /calendar/events.json.
  • On my own machine, the command also fails with --link and succeeds when only that argument is removed. The local CLI version and exact local error have not yet been captured for this report.
  • The same event and URL were successfully saved through the signed-in browser interface. CLI readback preserved the URL.
  • OAuth status, inbox reads and calendar reads work.

The reference is a private HTTPS HEY email-thread URL, omitted here. No public-URL reproducer has been verified, so this report does not establish that every --link value fails.

The argument was supplied as --link '<private HTTPS reference URL>' alongside the normal title, calendar, date, time-zone, location and notes options. The pinned CLI documents --link as "Meeting or reference URL" and passes Content.Link to calendar_event[url]. Current source uses the same mapping.

A diagnostics-only build preserving the request, authentication and transport found an HTML 403 body containing CAPTCHA/browser-challenge-related keywords. The provider and root cause are unknown; no raw body, credentials or headers are included here.

Expected

The CLI should accept the reference URL that HEY's browser form accepts, or return an actionable validation error.

Could you investigate the link-dependent failure and advise on a supported fix?

References
Dominant language
Go
Stars
412
Forks
52
Avg merge
22h 16m
Merged PRs (30d)
75

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from basecamp/hey-cli

All issues in basecamp/hey-cli

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.