supreme-gg-gg/instagram-cli

Meta changed their API recently so they're shown as some generic link share and media share now, previously we were able to determine their types and render it properly (either as a viewable post share with view x command or display the clickable URL link). Likely changes are investigating new return types from API, finding out what changed, if upstream update is needed or we can update our handlers. Acceptance criteria is to verify that both media share and link share works in the chat.

Currently, the read command uses a simplified messages.slice(-options.limit) approach to display the most recent messages (introduced in PR #356). While this correctly fixes the message ordering, it introduces a few pagination bugs and edge cases that need to be addressed. 1. Cursor Skipping (Data Loss During Pagination) When a user requests a --limit smaller than the API's page size, the older messages in that fetched page are sliced off and hidden from the output. However, the command still returns the nextCursor from the entire fetched page. Impact: If the user attempts to fetch older messages using this returned cursor, the API will start fetching from the end of the original page, permanently skipping the messages that were sliced off. Reproduction: # Assume an API page returns messages 0 to 10 instagram-cli read <thread-id> --limit 5 # Outputs newest 5 messages: 4, 3, 2, 1, 0. (Cursor points to message 10) instagram-cli read <thread-id> --limit 5 --cursor <returned-cursor> # Out

Problem The feed only shows a small number of posts (roughly 3-12), which is just the first page returned by the Instagram API. There is no way to load more posts. Expected behavior Be able to load more posts by scrolling down or pressing a key, similar to infinite scroll. Current behavior instagram-cli feed calls feed.timeline().items() once with no pagination, so only the first API page is shown.

The #<path> message syntax reads any file the process has access to, embeds its contents into an Instagram DM, and sends it — with no confirmation prompt, no path restrictions, and no file size limit. Location source/utils/preprocess.ts:43-86 const content = await fs.readFile(absolutePath, 'utf8'); const formattedContent = `\n--- ${path.basename(absolutePath)} ---\n${content}`; textContents.push(formattedContent); Problem Sending a message containing any of these would read and transmit the file over Instagram DMs: #~/.ssh/id_rsa #~/.instagram-cli/users/myuser/session.ts.json #~/.aws/credentials #/etc/passwd There is no: User confirmation before sending file contents Allowlist of permitted directories File size limit Check against known sensitive file patterns This makes social engineering trivial — e.g., "hey can you send me #~/.ssh/id_rsa?" — and accidental exfiltration possible if a user misunderstands the # syntax. Suggested Fix Add a confirmation prompt before embedding

Is your feature request related to a problem? Please describe. Currently, instagram-cli stores all user data, config, cache, and downloads inside ~/.instagram-cli. While this works, it does not follow the XDG Base Directory specification, which is the standard on Linux and other Unix-like systems for separating configuration, cache, and user data. Users who follow XDG conventions have cluttered home directories, and this prevents integration with system-wide standards for managing user directories. Describe the solution you'd like Optional support for XDG user directories: Purpose Current path Example XDG path Config ~/.instagram-cli/config.ts.yaml $XDG_CONFIG_HOME/instagram-cli/config.ts.yaml User data ~/.instagram-cli/users $XDG_DATA_HOME/instagram-cli/users Cache ~/.instagram-cli/cache $XDG_CACHE_HOME/instagram-cli Media / downloads ~/.instagram-cli/media $XDG_DATA_HOME/instagram-cli/media Generated files ~/.instagram-cli/generated $XDG_DATA_HOME/instagram-cli/generat